MySQL победил на Open Source Database the Benchmark

>не бубни урод.

>CREATE TABLE `date` (`date` DATE NOT NULL) ENGINE = MYISAM ; INSERT INTO `date` ( `date` ) VALUES ('2006-13-38');

Перестаньте газифицировать лужи.

INSERT INTO `date` ( `date` ) VALUES ('0000-00-00');

O_o?

Расскажите общественности, как называется _нулевой_ месяц года? Нуллябрь? Нульварь? А нулевой день - это тоже нормально, да?

Не говоря уж про нулевой год, что просто вАлшебно.

А давно ли можно сделать CHECK на поле? А полнотекстовый индекс построить по полю таблицы innodb? А связать через FOREIGN KEY таблицу типа myisam c полнотекстовым индексом и таблицу типа innodb?

причем здесь деньги?
я просто показал, что у MySQL очень хорошо оптимизирован процесс подключения к БД. На простых скриптах с парой-другой селектов (а в интернет магазине 90% запросов такие и будут, попробуй опровергнуть), MySQL легко выйдет вперед.

Я ОЧЕНЬ сомневаюсь, что на Oracle и прочия, за 6 миллисекунд вы сможете подключится к базе, сделать хотя бы один селект, и вывести результат. На любом языке интерфейса.
Кстати это все тестировалось на простом железе - Celeron 1.0 GHZ и 512 RAM.

>Оказывается, надо сделать ANALYZE.

во-во такие обычно и проводят подобные "тесты" :-). Не в обиду, а просто констатация факта :)

Вы бы, профессор, вначале хотя бы версией Мускуля у оппонента поинтересовались, а потом бы уже про газификацию рассказывали.

>за 6 миллисекунд вы сможете подключится к базе, сделать хотя бы один >селект, и вывести результат. На любом языке интерфейса.


>SELECT cg2.id as cg2_id, cg2.parent_id as cg2_parent_id, cg2.name as >cg2_name, cg2.is_deleted as
> cg2_is_deleted, cg2.create_date as cg2_create_date
> FROM core.groups cg2
> WHERE cg2.parent_id IS NULL
>query[7737160] binds: none
>[2006-08-31 19:08:13] [17386824] query[7737160]: exec time = 0.0040 sec
>[2006-08-31 19:08:13] [17386824] query[7737160]: all time = 0.0050 sec, 1 rows processed

за это время 0.0050 - произошло. Построился _объектный_ запрос (java) - передался по сети на соседнюю машину с ораклом (оракл стоит на p3 800 512 метров) - получили данные по которым построили объект (core.groups).
java работает на атлон 1ГГц. Постгресс работает примерно с такой же скоростью.

+ к этому происходит логирование каждого чиха (кусок лога).

> Я ОЧЕНЬ сомневаюсь, что на Oracle и прочия, за 6 миллисекунд вы сможете подключится к базе, сделать хотя бы один селект, и вывести результат. На любом языке интерфейса.

А нафига каждый раз подключаться к базе? Умные люди создают пул соединений. Еще не стоит забывать, что mysql блокировщик в то время как pg и oracle версионники. На разных задачах - разные плюсы и минусы.

Кстати 120 соединений в минуту говорят о прямом подключении к базе при каждой транзакции. И такие люди программируют...

приведите, пожалуйста соответствующий код на джава:
1. включение таймера
2. подключение к бд
3. посылка запроса
4. получение результата (1 строка)
5. распечатка через print или аналог
6. остановка таймера и вывод результата

- тогда это будет полный аналог кода на ПХП который я тестировал

> Недавно столкнулся с интересным фактом: почему-то один и тот же запрос к постгресу на боевом сервере выполняется 3 секунды, а на тестовой машине - 5 минут. Оказывается, надо сделать ANALYZE. Ускорение в 100 раз! %) Если предположить, что в сабже ситуация подобная, то можно поставить под сомнение итоговое распределение мест...

Последний месяц занимаюсь тем, что изучаю документацию по PostgreSQL - там про ANALYZE через слово говорится.

Вывод: доки вещь полезная.

А ещё для похожих запросов можно/нужно делать PREPARE

похоже вы измерили время выполнения запроса, а не общее время выполнения скрипта.

>Вы бы, профессор, вначале хотя бы версией Мускуля у оппонента поинтересовались, а потом бы уже про газификацию рассказывали.

И?

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 354793 to server version: 5.0.15
mysql> use test;
Database changed
mysql> CREATE TABLE `date` (`date` DATE NOT NULL) ENGINE = MYISAM ; INSERT INTO `date` ( `date` ) VALUES ('0000-00-00');
Query OK, 0 rows affected (0.27 sec)

Query OK, 1 row affected (0.00 sec)

mysql>

разницу между mysql_connect и mysql_pconnect я тоже замерил. И разница эта составила всего ДВЕ миллисекунды. Так что теория это хорошо, но факты вещь упрямая ;)

mysql>  CREATE TABLE `date` (`date` DATE NOT NULL) ENGINE = innodb;
Query OK, 0 rows affected (0.52 sec)

mysql> INSERT INTO `date` ( `date` ) VALUES ('0000-00-00');
Query OK, 1 row affected (0.01 sec)

Рекомендую почитать доку по date/time types в MySQL.
000-00-00 - это специальное "zero" value, документированое, и предназначенное как раз для случаев неправильных дат/времен

и что, отчет всегда начинается с нуля, или как ты неопределнную дату выводить собрался ? как false, как NULL (таблица задана как NOT NULL) или как 0000-00-01 ?
причем как назвать время, которое прямо между д.н.э и н.э или есть какойто определнный стандарт на это?

а все остальное, это спецефичные задачи, за связку индекса по словам между myisam и innodb руки имхо отрывать проектировщику базы надо.

>Рекомендую почитать доку по date/time types в MySQL. >000-00-00 - это специальное "zero" value, документированое, и предназначенное как раз для случаев неправильных дат/времен

Неправильная дата/время НЕ ДОЛЖНЫ вставляться в БД. Причем тут документирование такого поведения? Это кривое решение, нельзя допускать, чтобы оно вообще имело место.

Мне конечно мускуль нравится, но что-то неверится, что постгри ТАК сосёт :(

>а все остальное, это спецефичные задачи, за связку индекса по словам >между myisam и innodb руки имхо отрывать проектировщику базы надо.

Замечательно. Расскажите тогда, как _одновременно_ обеспечить полнотекстовый поиск И ссылочную целостность БД?

Или это очень специфичная задача - иметь БД с FOREIGN KEYS между таблицами и полнотекстовый индекс по полю?

http://dev.mysql.com/doc/refman/5.0/en/datetime.html

>Illegal DATETIME, DATE, or TIMESTAMP values are converted to the “zero” value of the appropriate type ('0000-00-00 00:00:00' or '0000-00-00').

вот так вот

>и что, отчет всегда начинается с нуля, или как ты неопределнную дату выводить собрался ?

Никак не собрался.

Почему вообще возникает вопрос как вывести неопределенную дату, полю, которому дан атрибут NOT NULL?

Почему не возникает вопросов, как вывести неопределенное значение из поля типа int, которому дан атрибут NOT NULL?

Почему не возникает подобных вопросов при использовании типов char, varchar, text?

> Неправильная дата/время НЕ ДОЛЖНЫ вставляться в БД. Причем тут документирование такого поведения? Это кривое решение, нельзя допускать, чтобы оно вообще имело место.

Оно не кривое, было бы кривое - давно бы уже подправили, поверьте. Оно просто УДОБНЕЕ. Иногда полезно иметь возможность помимо NULL записать в поле просто 0, которое и соответвует 0000-00-00 для DATE полей. А переложение на плечи интерфейса проверки валидности данных - это как раз хорошо. Иначе приходится иметь два слоя валидаторов - собственно данных, и валидности запросов для ДБ.

>Оно не кривое, было бы кривое - давно бы уже подправили, поверьте. Оно просто УДОБНЕЕ. Иногда полезно иметь возможность помимо NULL записать в поле просто 0, которое и соответвует 0000-00-00 для DATE полей. А переложение на плечи интерфейса проверки валидности данных - это как раз хорошо. Иначе приходится иметь два слоя валидаторов - собственно данных, и валидности запросов для ДБ.

Да как вы не поймете! Ну НЕ БЫВАЕТ нулевой даты. Нету месяца нульваря. Не бывает нулевого дня. Также, как не бывает минус одного ящика яблок.

ВременнОй интервал - бывает нулевым. А ДАТЫ НУЛЕВОЙ НЕ БЫВАЕТ. И в базе просто НЕЛЬЗЯ хранить такие данные и уж стократ ужаснее - то, что Illegal DATETIME, DATE, or TIMESTAMP values are converted to the "zero" value of the appropriate type ('0000-00-00 00:00:00' or '0000-00-00').

Это значит, что вставить можно ЛЮБОЙ БРЕД и база это проглотит не написав ни единой ошибки.

>>Почему вообще возникает вопрос как вывести неопределенную дату, полю, которому дан атрибут NOT NULL?

Например, поле с датой используется как поле в primary key.

СМЕЯЛСО

А что не так?

причем здесь бывает или не бывает нулевая дата... Просто удобнее (для разработчика), если она БЫВАЕТ и такую дату можно легко и удобно отловить по запросы WHERE `date`=0

>причем здесь бывает или не бывает нулевая дата... Просто удобнее (для разработчика), если она БЫВАЕТ и такую дату можно легко и удобно отловить по запросы WHERE `date`=0

Еще раз: НЕ НАДО ХОТЕТЬ отлавливать подобную сущность. Ее попросту не должно быть и все. Не надо создавать себе дополнительные проблемы и потом их героически преодолевать.

а чтобы такой сущности не было, надо просто грамотно валидировать входные данные, другое дело что я специально использую значение даты=0 в некоторых случаях

Там проводится на порядок больше действий - в основном построение объектного запроса. Мерять время подключения к базе - идиотизм, так как все нормальные люди используют пул коннектов.

никакого скрипта - это java. время выполнения запроса (отсылка запроса, обработка запроса, передача данных (по сети) 0.004) и 0.001 время на работу java. там времена написанны.

Я изучаю EJB3 с JBoss4 и Postgres 8 под Fedora Core 5 kernel 2.6.17 Сделал простой тест на вставку записей в одну тавлицу одновременно с трех клиентов, каждый вызывает одноименный EJB3 Bean где и запускается цикл на вставку 100000 записей. Я получил результат 26 сек.

>А переложение на плечи интерфейса проверки валидности данных - это как >раз хорошо. Иначе приходится иметь два слоя валидаторов - собственно >данных, и валидности запросов для ДБ.

это глупость - база данных ( _всегда_ ) должна быть в валидном состоянии, проверяют там что-то выше или нет. Всегда.

если вам так нравится обрабатывать ошибку БД в случае вставки неправильной даты (вместо того, чтобы проверять дату на входе) - пожалуйста поясните, как Вы это делаете и сообщаете пользователю о такой ошибке? Оччень интересно, как вы собираетесь парсить error output из базы и определять что именно проблема запроса в дате.

>НО - если учитывать также время подключения к БД, то время выполнения >скрипта отличалась почти ровно в ДЕСЯТЬ раз ! >Для MySQL - 6-7мс (!) >Для PostgreSQL - 55-65мс. >причем для MySQL НЕ использовалось mysql_pconnect. PostgreSQL был >нетюненый, но поставленный руками из сорцов, равно как и MySQL.

Вероятней всего это потому что MySQL использует потоки, в то время как PostgreSQL для каждого коннекта форкает отдельный процесс. Вот на эти форк время и тратится.

Пофлеймим на тему многопоточность vs многопроцессорность?)

> никакого скрипта - это java. время выполнения запроса (отсылка запроса, обработка запроса, передача данных (по сети) 0.004) и 0.001 время на работу java. там времена написанны.

там не учтено время ПОДКЛЮЧЕНИЯ к БД, которое и составляет 90% времени выполнения. Для PostgreSQL это время заставляет скрипт работать в 10 раз медленнее, чем аналог под MySQL. Время выполнения самого селекта вообще не играет особой роли - да и оно практически одинаково для разных баз/ У MySQL кстати оно составляет около 2-3 миллисекунд (сложно замерить точно)

>если вам так нравится обрабатывать ошибку БД в случае вставки >неправильной даты (вместо того, чтобы проверять дату на входе)

никто не говорит, что проверять надо только на стороне базы. Но в базу записать хрень, а потом проверять что туда записалось хрень или не хрень, нельзя ! А на попытку записать хрень база должна возвращать исключительную ситуацию.

>если вам так нравится обрабатывать ошибку БД в случае вставки неправильной даты (вместо того, чтобы проверять дату на входе) - пожалуйста поясните, как Вы это делаете и сообщаете пользователю о такой ошибке? Оччень интересно, как вы собираетесь парсить error output из базы и определять что именно проблема запроса в дате.

Не надо путать теплое с мягким.

Дату перед вставкой, безусловно, надо проверять в _приложении_.

Но __база__ не должна допускать вставку в себя неправильных данных.

К тому же, нормальные СУБД пишут цифровой код ошибки, который вполне себе конкретно описывает происшествие.

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

Я вот не очень понимаю, чем этот пул вам поможет в тестах на эффективность? Понятно, что если есть свободное время, то этот пул можно по мере его исчерпания пополнять, а в момент запроса выдавать клиенту уже готовое соединение из пула. Таким образом клиенту "кажется", что подключение произошло быстрее, чем оно на самом деле происходит. Но если свободного времени нет, то в какой-то момент времени пул просто исчерпается и его придется создавать вновь, что скажется на работе всего сервера баз данных. Так что я не очень понимаю ,почему создание пула может так радикально повысить производительность в тестах.

>там не учтено время ПОДКЛЮЧЕНИЯ к БД

ещё раз повторяю - те кто меряет время подключения к бд, могут идти в сад и дальше. Нормальные люди держат пул коннектов и их подобные дурости не волнуют - время подключения к БД это хуже сферического коня.

> Вероятней всего это потому что MySQL использует потоки, в то время как PostgreSQL для каждого коннекта форкает отдельный процесс. Вот на эти форк время и тратится. Пофлеймим на тему многопоточность vs многопроцессорность?)

А вот это уже более правильный ответ. И пока PostgreSQL нормально не будет работать с цепочками - не будет он конкурент MySQL по скорости обработки _простых_ запросов

>> Вероятней всего это потому что MySQL использует потоки, в то время как PostgreSQL для каждого коннекта форкает отдельный процесс. Вот на эти форк время и тратится. Пофлеймим на тему многопоточность vs многопроцессорность?)

>А вот это уже более правильный ответ. И пока PostgreSQL нормально не будет работать с цепочками - не будет он конкурент MySQL по скорости обработки _простых_ запросов

Вот именно поэтому и надо использовать пул коннектов.

>причем как назвать время, которое прямо между д.н.э и н.э

Гы. Уржаться. И этот человек пытается рассуждать о формате времени? :)

> Так что я не очень понимаю ,почему создание пула может так радикально повысить производительность в тестах.

Смотря как тестировать. Если сделать одновременно 1000 подключений, то пула не хватит, а если тест выполняет последовательные запросы, то хватит пула даже из одного соединения.

>Я вот не очень понимаю, чем этот пул вам поможет в тестах на >эффективность?

Мозг включить слабо ? или вообще почитать что такое пул. Произошло начальное подключение, данные отдались соединение не закрывается, а им может воспользоваться другой запрос у другого клиента через некоторое время. Пул не подымает производительность в "тестах", он подымает производительность в работе.

> ещё раз повторяю - те кто меряет время подключения к бд, могут идти в сад и дальше. Нормальные люди держат пул коннектов и их подобные дурости не волнуют - время подключения к БД это хуже сферического коня.

на 90% серверов, где крутится MySQL вам не дадут использовать пул коннектов, это раз. Второе - разница в ДВЕ миллисекунды при подключении через connect или pconnect не играет особой роли для MySQL.

> А вот это уже более правильный ответ. И пока PostgreSQL нормально не будет работать с цепочками - не будет он конкурент MySQL по скорости обработки _простых_ запросов

Не совсем так. Правильный ответ -- пока в mod_php не сделают по умолчанию пулл коннектов к PostgreSQL, большинство будет счиать что PostgreSQL не конкурирует по скорости обработки _простых_ запросов с MySQL.

По поводу нитей, об этом в FAQ написано: http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.13

>А вот это уже более правильный ответ. И пока PostgreSQL нормально не >будет работать с цепочками - не будет он конкурент MySQL по скорости >обработки _простых_ запросов

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

>>если тест выполняет последовательные запросы, то хватит пула даже из одного соединения.

Вот этого я как раз не понимаю. Есть пул из одного соединения, пришел запрос, клиенту дали соединение из пула. После этого пул опустел и нужно его заполнить, перед тем как придет следующий запрос. Но ведь тест измеряет число подключений в минуту (те измеряет и время на пополнение пула) и хочется чтобы это число было как можно больше. Так что в итоге время подключение к базе в таких тестах решает всё.

> Просто надо писать приложения нормально - через пул коннектов и тогда простые запросы в постгре будут летать и работать будет быстрее, чем приложения "могучих" мускулистов, которые каждый раз коннектятся.

Чушь какая то, вы читали посты выше? БЕЗ пула коннектов MySQL быстрее PostgreSQL в десять раз если замерять время соединения. Если С пулом коннектов, то разница будет еще больше.

>на 90% серверов, где крутится MySQL.

??? кто мне что запретит ? какими это средствами ? (я честно говоря только с дедикейт серверами имею дело, поэтому не совсем шарю, что там на "дешёвом" хостинге)