MySQL 5.0 RC1

прочитал. Круто. Может через некоторое время действительно потеснит остальные "серьезные" СУБД на рынке/ Много вкусностей + простота администрирования, установки и т.д

О как! И десяти лет не прошло, как... А точки сохранения в транзакциях когда будут? :)

Нетушки, братцы, поезд уехал. Жжот постгрес, мускуль нервно дымится в сторонке... :D

> Может через некоторое время действительно потеснит остальные

_очень_ много времени должно пройти (3-5 лет). слишком долго mysql позиционировал себя, как дешевую говнобазу для бедных

--седайко стюмчик

Для бедных?
Да вы просто не в теме.

Yahoo!, Google, Suzuki, CNN, Alcatel и т.д. (см http://www.mysql.com/customers/) бедные?

MySQL имеет свой рынок и очень очень неплохой.

> Жжот постгрес, мускуль нервно дымится в сторонке... :D

А главное - где теперь легковесные sql для web? ;-)

насколько я знаю, постгрес дико тормозит по сравнению с мускулем.

SQLite, думается... Как записная книжка. Для пхорумов даже текстовые файлы пойдут.

А вы его умеете готовить? Когда-то 3.23 был тоже "офигенно быстрым". В сравнении с, именно что. Даю ему несложненький SQL по простым, только вот немаленьким табличкам, и там затесываются два LEFT JOIN'а. Сервер встает раком. Постгрес же хоть и не так молниеносно быстр, но у него с такими вещами, во всяком случае, порядок, ибо это еще азы...

А еще у постгреса есть довольно информативный, в сравнении с, EXPLAIN, который эту тормознутость делает возможным предсказать. И предотвратить при наличие головы в надлежащем месте.

да, на самом деле мы плотно работаем с 4.0 (теперь с 4.1). Транзакции, сложные джоины и т.п. в полный рост. Моё имхо: во всём, кроме скорости, база - говно, да и скорость у них всё хуже и хуже. А в 3.23 просто не было innodb.

Но про постгрес я сказал посмотрев кучу бенчмарков в сети, чё-то он везде сливает по производительности. Мускуль хоть можно оттюнить если напрячься, я вот с ним что будет - хз.

> SQLite, думается... Как записная книжка. Для пхорумов даже текстовые файлы пойдут.

А оно же не тхред-сейф.
Тхред-пуллы каждый раз писать не предлагать.

> А оно же не тхред-сейф.

А что там не thread safe? Вроде в доках писалось об обратном...
(не флейма ради, действительно интересно)

Как где? Поправьте меня если я не прав, но MySql не вводит новую функциональность в MyISAM. MyISAM как была куцей и шустрой так и осталась.

Если кому то необходимо возможности "больших" СУБД от MySQL обратите внимание на продукт MaxDB он как раз и позиционируется как замена Oracle, да и режим совместимости есть.

> Транзакции, сложные джоины и т.п. в полный рост.
ага, а их SERIALIZABLE достоин аваций.
> Но про постгрес я сказал посмотрев кучу бенчмарков в сети, чё-то он везде сливает по производительности.
там обычно древний постгрес или/и только MyISAM, свежий тест: http://monstera.man.poznan.pl/wiki/index.php/Mysql_vs_postgres
на InnoDB мускуль селектит быстрее, но сливает восьмеркe в остальном
> Мускуль хоть можно оттюнить если напрячься.
в постгресе за тебя обычно напрягается планировщик и мне это больше нравится

> Если кому то необходимо возможности "больших" СУБД от MySQL обратите внимание на продукт MaxDB он как раз и позиционируется как замена Oracle, да и режим совместимости есть.

куда ему без MVCC

"Но про постгрес я сказал посмотрев кучу бенчмарков в сети, чё-то он везде сливает по производительности"

Это все фигня, а не тесты. Нужно на своих задачах тестить. Я тестил. Постгресс рвет mysql. А уж если вспомнить по нативный тип данных IP и продакшн-патч pg-hier (деревья в sql), то все еще веселее.

"Мускуль хоть можно оттюнить если напрячься, я вот с ним что будет - хз."

:) "Не читал, но осуждаю!" Постгресс как раз замечательно тюнится, и это делать обязательно, т.к. поставка по-умолчанию настроена на запуск где угодно, а не на скорость. Ну и тюнинг ведь делается под конкретную структуру базы, а не под некую сферическую базу.

э, народ!!!так нв что с оффSQl переходить... я на MySQL собирался

berkleyDB упраздняет mysqllite и mysql пожалуй тоже

круто, блин!
хочешь - функциональность, хочешь - непревзойденная скорость.
и, что характерно, под ГПЛ!

>насколько я знаю, постгрес дико тормозит по сравнению с мускулем

это у красноглазых криворуких пионеров только. верящих в "серебрянную пулю".

признайся, настройку производительности ты в доках (замечательных! мускулевские курят по сравнению с) не искал

да ну вас, все равно все сливают Firebird :)

К сожалению разработчиков MySQL их попытки тщетны. База отлично подходит для форумов и записных книжек и далее целесообразность её применение заканчиваеться. Хотя очень жаль.

По поводу Firebird'а (кто не в курсе - клон Interbase) - must have! Маленький и удаленький, прост в освоении, с тучей возможностей. Короче полноценная промышленная СУБД, которая может с успехом использоваться во встраиваемых системах вследствие своей легковесности! Аминь. :)

Вот мне постгресс вроде больше нравится, но очень большим плюсом MySQL лично я считаю наличие полностью переведенной на русский документации, привычнее, знаете ли. А мои задачи <10 пользователей и базы не очень быстро растут. Поэтому пока MySQL.

Firebird уж очень однопоточен (про v.2 говорить не надо - там еще не известно что получится) + у меня еще на IB5.5 постоянно возникали проблемы с целосностью данных на базах более 50MB (сначала базы были маленькими, а потом начальству захотелось хранить больше данных, так что дешевле брать базу с хорошим запасом мощности),

после появления в MySQL triggers & views мне в нем не хватает только аналитических функций (да, это далеко не Oracle), да и то они не везьде нужны

а как критерий качества написания предлагаю сравнить кол-во исправленных ошибок при выходе версий-bugfix'ов думаю здесь качество программы важнее "фичастости"

По поводу Firebird'а (кто не в курсе - клон Interbase) - must have! Маленький и удаленький, прост в освоении, с тучей возможностей. Короче полноценная промышленная СУБД, которая может с успехом использоваться во встраиваемых системах вследствие своей легковесности! Аминь. :)
--------
ага без лога транзакций, с кривым оптимизатором (помесь cost based и rule based), отсутсвует cursor stability (т.е. inset into table select * from table зациклится навсегда) и прочее ... короче замечательная субд.

--
Kio

>> Если кому то необходимо возможности "больших" СУБД от MySQL обратите внимание на продукт MaxDB он как раз и позиционируется как замена Oracle, да и режим совместимости есть.

> куда ему без MVCC

кто таков MVCC?

люди, а подскажите, где можно нормально почитать о тюнинге постгреса..
а то в доках как-то всё расплывчато :)
конкретно интересует как её настраивать на большое кол-во процов и памяти

> кто таков MVCC?
Multiversion Concurrency Control (MVCC)
Перевод: технология MVCC, технология MVCC (Multiversion Concurrency
Control, управление конкурентным доступом с помощью многоверсионности)

>berkleyDB упраздняет mysqllite и mysql пожалуй тоже

berkeley хорошь когда 1 индекс на таблицу. А как надо еще индексов добавить вот и начинается е@ля с пляской.

в 5.0 vacuum появился - ну все хана mysql ... ( помню кричали mysqlцы - что у нас круто vacuum не нужен .. )

В топку эту поделку.
Если база больше 100 метров будут исключительно глюки и гемор.
А уж как она любит повредить собственный файл базы данных... ммм...

> Поправьте меня если я не прав, но MySql не вводит новую функциональность в MyISAM.

Ну, не то, что бы совсем не вводит. Скажем, в 4.1+ даже в MyISAM текст в UTF-8 хранится... ;-) Потом, вводят не вводят, а работает-то ядрышко, новые SQL операторы поддерживаются, что само по себе не плохо, но местами - излишне. :)

> Даю ему несложненький SQL по простым, только вот немаленьким табличкам, и там затесываются два LEFT JOIN'а. Сервер встает раком.

Подтверждаю. MySQL 4.1 Табличка на 4.6 ляма записей, ~ 450 Мб. Сложный запрос, с join - 25 минут просто, 20 сек, после того, как обиндексировал всё, что только можно. Причём в explain ничего криминального не было. Тормозил даже не на join, а на where (сложный был). Выкрутится получилось разбив запрос на 5 мелких и склеив их union. В результате ~0.01 сек, что для мелкого веб-сайта подошло...

2atrus:
А можно подробности? Я занимаюсь этой темой.
можно на мыло apachephp на gmail.com

-rw-rw----    1 mysql    mysql    4105608423 Sep 28 12:49 data.MYD
-rw-rw----    1 mysql    mysql    7724321792 Sep 28 12:49 data.MYI

Не надо гнать. Работает 4 года, начиналось еще на 3.x, сейчас 4.1.13, 100% uptime.

Не тестируйте вы скорость одного SQL запроса. Протестируйте лучше более глобальную задачу. Например поиск товаров которые продаются в сумме от Х до У в месяц. На мускуле это прийдётся решать количеством мелких запросов. На Постгресте одним запросом. Теперь проверте это всё с нагрузкой в 3-5 паралельный выполнений... Всем стало ясно ?

ЗЫ большее количество запросов даёт ещо и нагрузку на сеть, переключение контента, больше работы драйвера ДБ.

В том то и прикол что на мускле много маленьких запросов пролетают быстрее чем один большой

> кто таков MVCC?
http://en.wikipedia.org/wiki/Mvcc

> Подтверждаю. MySQL 4.1 Табличка на 4.6 ляма записей, ~ 450 Мб. Сложный запрос, с join - 25 минут просто, 20 сек, после того, как обиндексировал всё, что только можно.

Вообще-то джойны в сравнении с тройкой поднялись и это я оценил по праву (на тех же данных), но многое все равно надо делать на уровне не СУБД, а приложения, и это напрягает.

В тройке обиндексирование мало что дает (пробовал, после чего плюнул).

по всей видимости работает только insert в базу... а смысл? задача какая, вы бы пояснили, а то я сейчас тоже dd of=data.MYI сделаю и скажу что работает как часы.

Думаю, всё зависит от вида запросов. У меня, например, таблица myisam примерно такого же объема рушится не реже раза в сутки. Уже автовосстановление сделано специально для этого. Только изменения происходят сразу блоками строк - заменой одного блока на другой (при использовании lock tables). Несрабатывают всегда транзакции удаления. 4.1.14.

Схемы есть? Композитные типы есть? Нет? Фтопку =)

2Sources:
Я бы рекомендовал заполнить bug
на http://bugs.mysql.com/. Это критический bug и его пофиксят as soon as possible.

Если бы я мог предугадать, когда запрос сработает, а когда - нет, тогда бы запостил. Им же примеры нужны. Всё, что я могу сказать - это "иногда не работает". Не один я это говорил и ранее.

> признайся, настройку производительности ты в доках (замечательных! мускулевские курят по сравнению с) не искал

перечитай мой пост ещё раз. подумай. сам ответь на свой вопрос.

Отсутствие лога транзакций - это его преимущество, т.к. в основу положена многоверсионность транзакций - это гораздо надёжнее. Остальные аргументы, особенно - ' и прочее ... ' просто смешны. Короче - не гони!

у меня несложная myisam таблица на 2 млн срок ( ip, путь к файлу, имяфайла) для поиска файлов. дык простой %like% отрабатывает больше минуты на 4.1.11 :((( Хоть на оракл переходи

Юзай Classic вариант и будет тебе многопоточность и даже "многопроцессность" за счёт создания на каждое клиентское приложение отдельного процесса и соответственно планирование выделения процессорного времени на обслуживание клиентов фактически ляжет на плечи планировщика заданий ОС.

> у меня несложная myisam таблица на 2 млн срок ( ip, путь к файлу, имяфайла) для поиска файлов. дык простой %like% отрабатывает больше минуты на 4.1.11 :((( Хоть на оракл переходи

Oracle не даст существенного прироста производительности для твоего запроса. Если реально нужно делать такой like по всем строкам, то нужно улучшать параметры железа (особенно памяти и процессора) и правильно настроить mysql на использование большего количества памяти.