Разработчики MySQL AB выпустили первую production-версию MySQL 4.1.7 (http://dev.mysql.com/doc/mysql/en/News-4.1.7.html).
Список значительных отличий от 4.0:<ol>
- Поддержка подзапросов (subqueries).
- Быстрый бинарный клиент-серверный протокол с поддержкой подготовленных (prepared) запросов и привязкой (binding) параметров.
- Быстрое дублирование структуры таблицы:
CREATE TABLE tbl_name2 LIKE tbl_name1
- MyISAM теперь поддерживает пространственные типы данных OpenGIS для хранения географических данных.
- Кодировка теперь может быть указана конкретно для колонки, таблицы и базы данных.
- Клиент в любой момент может установить любую временную зону (timezone).
- У сервера теперь появилась команда HELP, с помощью которой клиент может получить справку по той версии SQL, которая поддерживается этим сервером.
</ol>Процесс обновления версии 4.0 до 4.1 описан в документе "Upgrading from Version 4.0 to 4.1 (http://dev.mysql.com/doc/mysql/en/Upgrading-from-4.0.html)", частичный перевод на русский язык доступен здесь (http://dev.mysql.com/doc/mysql/ru/Upgrading-from-4.0.html).
URL: http://dev.mysql.com/downloads/mysql/4.1.html
Новость: http://www.opennet.me/opennews/art.shtml?num=4563
атлична!! так держать. особенно порадовало копирование структуры таблицы - можно применять иногда
а еще очень "вкусные" функции для работы с датами.
А еще вкуснее снести все это нафиг и поставить PostgreSQL, который при прямых руках и правильной настройке будет даже на простых и частых запросах работать сравнимо с MySQL по скорости, а вот возможностями он MySQL превосходит настолько, что MySQL доползет до них года через два-три, если вообще доползет. :-)Сорри за оффтоп. :-)
извечное противостояние слона и дельфина :-)
а если по офтопу: кто бы спорил.
Модификация:
А еще вкуснее снести все это нафиг и поставить Oracle 10g, который при прямых руках и правильной настройке будет даже на простых и частых запросах работать сравнимо с Postgres по скорости, а вот возможностями он Postgres превосходит настолько, что Postgres доползет до них года через два-три, если вообще доползет. :-)"Oracle 10g" можно заменить на IBM DB2, Sybase ASE или Informix Dynamic Server, кому что по вкусу.
Гы :) И крутить на этом самом оракле табличку 10х200 для локального почтовика :)Все хорошо в меру :) Там где нужен мускуль, ни постгрес, ни оракла тем более не нужны. Это еще не считая того, что за ораклу прийдется заплатить.
>Гы :) И крутить на этом самом оракле табличку 10х200 для локального
>почтовика :)
>
>Все хорошо в меру :) Там где нужен мускуль, ни постгрес, ни
>оракла тем более не нужны. Это еще не считая того, что
>за ораклу прийдется заплатить.Вообще-то за все нужно платить.
Либо за софт, либо за настройку этого софта, либо программисту за написание дополнительных программ для работы с этим софтом.
MySQL разрастается возможностями - это хорошо, поле его применений расширяется. Так, где раньше нужен был Postgres или что-то посерьезней скоро будет хватать и MySQL. Меньше разных СУБД в системе - уже хорошо. Для администратора :)
Я имел ввиду платить за сам софт :) К любой базе в юбо случае нужен администратор :)
Больше баз - больше выбора. Там, где раньше был мускуль, наверняка скоро окажется sqlite.
А позвольте не согласиться? ;-)В PostgreSQL, мне, например, очень не хватает того набора типов данных, который поддерживается MySQL. В MySQL-таблице можно сделать колонку, которая будет занимать, во внутреннем представлении, 1 (да, всего один) байт. Те таблицы, которые у меня занимают по 6 GB, в варианте для PostgreSQL -- 18 GB, и более... Что уж говорить, про размеры MySQL-баз в 30 GB? Так что, вы уж извините, но снести нафиг, зачастую приходилось PostgreSQL. ;-) А вообще, я как считал, так и считаю по-прежнему, что нужно знать разные инструменты, чтобы выбирать наиболее подходящие в каждом конкретном случае. ;-)
http://dev.mysql.com/tech-resources/crash-me.php
/poige
--
http://www.i.morning.ru/~poige/
Вы извените, но я недавно начал осваивать постгрис, и сказать поправде не могу нарадоваться. Возможностей куча. Сейчас
дописываю на нем биллинг. Такого я б на мускуле не сделал, все внутри бази,
тоесть в базу приходит только ip accounting а дальше "база" сама считает. И производительность приятно удивляет :)Реализован выбор сетевой зони для трафика, я и не думал что это будет так бистро на постгрис :) в базе около полтори тисячи сетей /19 - /24.
Да диска жрет больше, но я ему это прощаю :) ибо компенсирует он это другими
вкусностями :). Место мне не расходится (масив 240 Гб)я выбираю постгрис.
Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ к более быстрым выборкам. ;-)При sequential reading, и прочих равных условиях, выборка будет в 3-и раза быстрее, поскольку читалось в 3-и раза меньше GB. :-)
Что касается выбора "MySQL or PgSQL?" применительно к задачам статистики трафика, явно лучше первый, я занимался этим немало времени и могу говорить уверенно. Приведу, пожалуй, чтобы дать вам представление о масштабах, кол-во записей в одной из таблиц:
count(*): 778693837
P. S. Выдержка из доки по MySQL:
"...
One of the most basic optimizations is to design your tables to take as little space on the disk as possible. This can give huge improvements because disk reads are faster, and smaller tables normally require less main memory while their contents are being actively processed during query execution. Indexing also is a lesser resource burden if done on smaller columns.
..."/poige
А как же триггеры, процедури, views?
Разве можно без этого? Разве удобно?
Да и зачем засовывать в БД такое количество информации,
у меня для каждого клиента в день по ~8 записей.
Да и вообшче, что это за СУБД которая умеет 4 операции?(SELECT,INSERT etc.)привожу реальний пример, таже база перенесена без конструктивных изменений
с мускула в постгрис, так постгрис на 20% бистрее обрабативает те же запросы, а данных только прибавилось .>Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ
>к более быстрым выборкам. ;-)
>
>При sequential reading, и прочих равных условиях, выборка будет в 3-и раза
>быстрее, поскольку читалось в 3-и раза меньше GB. :-)
>
>Что касается выбора "MySQL or PgSQL?" применительно к задачам статистики трафика, явно
>лучше первый, я занимался этим немало времени и могу говорить уверенно.
>Приведу, пожалуй, чтобы дать вам представление о масштабах, кол-во записей в
>одной из таблиц:
>
> count(*): 778693837
>
>P. S. Выдержка из доки по MySQL:
>
>"...
>One of the most basic optimizations is to design your tables to
>take as little space on the disk as possible. This can
>give huge improvements because disk reads are faster, and smaller tables
>normally require less main memory while their contents are being actively
>processed during query execution. Indexing also is a lesser resource burden
>if done on smaller columns.
>..."
>
>/poige
>А как же триггеры, процедури, views?
>Разве можно без этого? Разве удобно?Для данной задачи -- вполне. Вот в качестве БД для RADIUS'а,
PgSQL неплохой выбор. Хотя, опять же, зависит от того, кто, и что желает получить в итоге.>Да и зачем засовывать в БД такое количество информации,
Людям приятно знать больше. ;-)
/poige
>Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ
>к более быстрым выборкам. ;-)А теперь сравни MySQL/InnoDB с PostgreSQL :-) Никакими быстрыми выборками там и не пахнет, когда дело касается транзакций и средств для контроля целостности.
>При sequential reading, и прочих равных условиях, выборка будет в 3-и раза
>быстрее, поскольку читалось в 3-и раза меньше GB. :-)Вообще-то частые "sequential reading" на больших таблицах больше проблема проектирования базы :-)
>Что касается выбора "MySQL or PgSQL?" применительно к задачам статистики трафика, явно
>лучше первый,Только вот под FreeBSD под очень большой нагрузкой не хочет MySQL нормально работать, до сих пор. Но треды сами по себе ресурсов жрут конечно меньше, чем форки PostgreSQL. Для кучи мелких операций, таких как учет трафика, MySQL отличное решение, хотя я все больше в сторону SQLite смотрю.
> count(*): 778693837
И часто "sequential reading" случается делать ? ;-)
Кстати, проведи эксперимент с базой такого объема в InnoDB.
>>Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ
>>к более быстрым выборкам. ;-)
>
>А теперь сравни MySQL/InnoDB с PostgreSQL :-) Никакими быстрыми выборками там и
>не пахнет, когда дело касается транзакций и средств для контроля целостности.хватает MyISAM! :-)
>
>
>>При sequential reading, и прочих равных условиях, выборка будет в 3-и раза
>>быстрее, поскольку читалось в 3-и раза меньше GB. :-)
>
>Вообще-то частые "sequential reading" на больших таблицах больше проблема проектирования базы :-)про __частые__ где говорилось? :-)
>
>
>>Что касается выбора "MySQL or PgSQL?" применительно к задачам статистики трафика, явно
>>лучше первый,
>
>Только вот под FreeBSD под очень большой нагрузкой не хочет MySQL нормально
>работать, до сих пор. Но треды сами по себе ресурсов жрутмне есть из чего выбирать OS -- *BSD, Linux, Solaris.
Вообще, то, что тут описано
http://dev.mysql.com/doc/mysql/en/FreeBSD.html
пробовал?
>конечно меньше, чем форки PostgreSQL. Для кучи мелких операций, таких как
>учет трафика, MySQL отличное решение, хотя я все больше в сторону
>SQLite смотрю.
>
>> count(*): 778693837
>
>И часто "sequential reading" случается делать ? ;-)не. sequential чаще (когда любопытно) делается на
count(*): 351983119
Упирается, кстати, не в диск, а CPU. :-)
>Кстати, проведи эксперимент с базой такого объема в InnoDB.
Не нужен мне InnoDB, в этой задаче. Не нужен. ;-)
/poige
а года через 3 sqllite дорастет до уровня сегодняшнего mysql и тогда появиться sqlsuperlite, а если серьезно то я считаю такое разрастание mysql нехорошим делом, ибо он начинает толстеть и сувать нос туда где постгрес правит а из своей ниши уходить.
Да и шут с ним. На самом деле было бы сдорово собирать мускуль только с теми фичами, которые конкретно нужны. Мне, к примеру, нужна совместимая записаня книжка. Все новомодные приболуды мускуля я просто не юзаю.