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

Скажу больше ;-) Основаная таблица чуть более 45000000 записей, к ней с полсотни связанных справочников, некоторые порядка 8000000 записей, санковский сервер приложенийб на нем ejb и сервлеты + oracle. заливка первичкой с нуля (через ejb, все данные + сервлеты дергают ejb компоненты на других серверах приложений санковских) занимает чуть более 10 часов. Индексирование при этом частичное, потом еще накатываются более тонкие индексы, которые сильно влияют на вставку. Целостность и актуальность данных не вызывает сомнений ;-)

Покажите мне это на мускуле ;-), вот postgres справляется тоже, но он у нас занимается чуток другими вещами.

> Ты тупой или прикидываешься ? Сколько из тех 300 хостов сделают ОДНОВРЕМЕННЫЙ запрос в базу ? По статистике не больше 2%-5% для средненавороченного приложения. Значит нужно будет всего лишь 6-15 ПОСТОЯННЫХ коннектов к базе, которые после запроса ТУТ ЖЕ ВОЗВРАЩАЮТСЯ В ПУЛ!

Это смешно. Ознакомтесь сначала с работой пула в MySQL. До истечении времени wait_timeout соединение с клиентом не будет закрыто (если коиент его сам не закрыл). Это время измеряется часами, т.е достаточно эти 300 запросов сделать в течении нескольких часов (пока у первых соединений не истекло wait_timeout), чтобы положить базу в случае pconnect. В случае connect только одновременные 300 запросов положат базу. Теперь надеюсь понятно?

> Я же в свою очередь рекомендую ознакомиться с тем, что же такое пул, как Вам уже здесь неоднократно советовали. Соединения _переиспользуются_.

Вообще то мы говорили о запросах с уникальных хостов при pconnect. Такой кстати баг имеется (имелся) в MySQL, когда переиспользовалось одно и тоже соединение для разных клиентов, вы это имеете в виду?

> Вообще то мы говорили о запросах с уникальных хостов при pconnect.

Не знаю, о чем Вы говорили, а в данной теме говорится об использовании связки web-сервер со скриптовым языком + сервер БД. Сколько уникальных хостов в такой связке? Столько же, сколько web-серверов, то есть, обычно ровно 1. Если Вы в своих проектах даете пользователям php-скрипт и удаленный доступ к базе, то это уже другой разговор, к данной теме отношения не имеющий.

>В случае connect только одновременные 300 запросов положат базу. Теперь надеюсь понятно?

Нет, это Вы чего-то не понимаете.

Еще раз и медленно: у меня есть виртуальный хост, на котором крутится тот же вебмагазин.

Я создаю 10 (20, 30, 50) одновременных подключений к базе (пусть это будет простой массив из пар значений {MYSQL * conn, bool busy_flag } ). http://dev.mysql.com/doc/refman/5.1/en/mysql-connect.html

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

Как только я обрабатываю запрос пользователя (показываю ему хтмл-страницу, например) я помечаю это соединение как свободное.

Вот и весь алгоритм.

О каких wait_timeout ВООБЩЕ ИДЕТ РЕЧЬ?

Все тоже самое я могу сделать и с Постгресом, ДБ2, Ораклом и т.д.

> Не знаю, о чем Вы говорили, а в данной теме говорится об использовании связки web-сервер со скриптовым языком + сервер БД. Сколько уникальных хостов в такой связке? Столько же, сколько web-серверов, то есть, обычно ровно 1. Если Вы в своих проектах даете пользователям php-скрипт и удаленный доступ к базе, то это уже другой разговор, к данной теме отношения не имеющий.

Суть дела станет более ясна для вас, если задумаетесь о максимальном времени жизни apache/php процессов. Также посмотрите типичное значение KeepAlive. Рекомендую также подумать почему запросы HTTP 1.0 к php/apache положат базу быстрее чем HTTP 1.1.

> Далее, как только ко мне приходит запрос, я выбираю первое попавшееся свободное соединение, помечаю его как занятое и работаю с базой через него.

кто в вашем случае помечает соединение как свободное?

>> Далее, как только ко мне приходит запрос, я выбираю первое попавшееся свободное соединение, помечаю его как занятое и работаю с базой через него.

>кто в вашем случае помечает соединение как свободное?

Я сам, после того, как закончу работу с базой для данного запроса пользователя.

нету в PHP такой возможности. только mysql_close который вызывает соответствующую MySQL C API функцию.

Представьте, что очередной запрос к базе отрабатывает другой процесс apache/php (после окончания KeepAlive например или при HTTP 1.0 запросе). Каким образом они могут использовать общий пул? С точки зрения базы - запрос с другого процесса php это запрос с другого клиента/хоста. База не может повторно использовать соединение, если не истекло время wait_timeout, и нету возможности определить, используется еще соединение или уже нет

>нету в PHP такой возможности. только mysql_close который вызывает соответствующую MySQL C API функцию.

Причем тут PHP?!

Где, НУ ГДЕ сказано, что PHP - единственно возможный ЯП для веба? Вы, простите, читать не умеете, или специально игнорируете тот факт, что в тестах в том числе использовалась и Java?

> Причем тут PHP?! Где, НУ ГДЕ сказано, что PHP - единственно возможный ЯП для веба? Вы, простите, читать не умеете, или специально игнорируете тот факт, что в тестах в том числе использовалась и Java?

мы вообще-то обсуждали разницу в быстродействии MySQL/PHP и PostgreSQL/PHP решений в данном тестировании (см. посты выше). Я написал, что время соединения postgreSQL и MySQL отличается на порядок. И это разница может довольно сильно влиять на конечную производительность скриптов интернет магазина.

>Представьте, что очередной запрос к базе отрабатывает другой процесс apache/php (после окончания KeepAlive например или при HTTP 1.0 запросе). Каким образом они могут использовать общий пул? С точки зрения базы - запрос с другого процесса php это запрос с другого клиента/хоста. База не может повторно использовать соединение, если не истекло время wait_timeout, и нету возможности определить, используется еще соединение или уже нет

Почему *процесс* а не *нить* (thread), Почему ВООБЩЕ Apache, а не Application Server back-end + Apache front-end?

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

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

> Почему *процесс* а не *нить* (thread), Почему ВООБЩЕ Apache, а не Application Server back-end + Apache front-end?

а это потому что 90% процентов интернет магазинов сделаны на LAMP.

>> Почему *процесс* а не *нить* (thread), Почему ВООБЩЕ Apache, а не Application Server back-end + Apache front-end?

>а это потому что 90% процентов интернет магазинов сделаны на LAMP.

Вы жестоко ошибаетесь. Вебмагазины с 1000+ заказов в секунду никто на LAMP не пишет. Мы же рассматриваем именно высокопоизводительные решения.

2anonymous-III

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

Учитывая убогую систему прав и привилегий в MySQL, нижеприведенный результат вполне нормален:

$ time sqlplus system/*****@***** @dual;

SQL*Plus: Release 10.1.0.3.0 - Production on Fri Sep 1 14:29:40 2006

Copyright (c) 1982, 2004, Oracle. All rights reserved.

Connected to: Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production JServer Release 9.2.0.7.0 - Production

D - X

Disconnected from Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production JServer Release 9.2.0.7.0 - Production

real 0m0.156s user 0m0.027s sys 0m0.028s

хоть бы http://pgpool.projects.postgresql.org/ заюзали

а кто говорит о магазинах с 1000+ заказов в секунду? Вы сами это придумали.

Я не в курсе как в СНГ/Европе, но среднестатистическому заказчику-американцу для своего личного интернет магазинчика хватает за глаза потолка в 5-10 запросов в секунду. Для них PHP/MySQL - самое то. Подавляющее большинство заказов - именно на такие проекты. Таких магазинов на несколько порядков больше чем тех, которые обрабатывают 1000+ в секунду.

о чем и речь. MySQL благодаря более простой организации распределения прав доступа (в том числе) гораздо эффективнее оказывается на легких задачах.

>а кто говорит о магазинах с 1000+ заказов в секунду? Вы сами это придумали. >Я не в курсе как в СНГ/Европе, но среднестатистическому заказчику-американцу для своего личного интернет магазинчика хватает за глаза потолка в 5-10 запросов в секунду. Для них PHP/MySQL - самое то. Подавляющее большинство заказов - именно на такие проекты. Таких магазинов на несколько порядков больше чем тех, которые обрабатывают 1000+ в секунду.

Какой же Вы сложный....

Я НИЧЕГО НЕ ПРИДУМАЛ

Прочтите, о чем предмет дискуссии. http://www.heise.de/ct/05/20/156/ http://firebird.sourceforge.net/connect/ct-dbContest.html

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

Короче, определитесь для начала с предметом. Чесслово, достали подобные вихляния по теме.

о чем предмет дискусии - потрудитесь прочитать еще раз мой пост выше:

> мы вообще-то обсуждали разницу в быстродействии MySQL/PHP и PostgreSQL/PHP решений в данном тестировании (см. посты выше). Я написал, что время соединения postgreSQL и MySQL отличается на порядок. И это разница может довольно сильно влиять на конечную производительность скриптов интернет магазина.

> Суть дела станет более ясна для вас, если задумаетесь о максимальном времени жизни apache/php процессов.

Ну ладно. Значит, дело в реализации web-сервера? Дескрипторы соединений в общем случае никто не запрещает передавать между процессами. Как насчет Apache2?

>MySQL/PHP и PostgreSQL/PHP

Просто хреново написаны интерфейсы к базам и все. Что тут еще обсуждать? СУБД не виновата в том, что у разработчиков PHP-extensions криво настроены руки....

тут дело скорее не в интерфейсах. Дело в разной архитектуре баз. Я сомневаюсь, что PostgreSQL когда либо обгонит MySQL на этапе установки соединения. Пул соединений для PostgreSQL не сильно поможет, как ни помогает он в MySQL, а проблем добавляет изрядно. Достаточно вспомнить время, когда pconnect вообще нельзя было использовать нормально - он просто не отдавал соединения. У же не помню, при каких версиях PHP/MySQL был этот баг.

> Ну ладно. Значит, дело в реализации web-сервера? Дескрипторы соединений в общем случае никто не запрещает передавать между процессами. Как насчет Apache2?

буду рад услышать от вас что изменилось в Apache 2.

по сцылке на pgpool не ходили ?

ходил. Полезное решение для некоторых ситуаций. Однако как видно на графике, при нагрузке до 60 параллельных соединений оно проигрывает обычному методу доступа к базе, а после этого - лишь незначительно опережает. Неясно кстати, будет ли вообще преимущество на реальных преложениях - т.е куча процессов php/apache работающих с разными хостами, каждый имеет свой connection к базе и т.д... Это проверяется только экспериментально.

> буду рад услышать от вас что изменилось в Apache 2.

В 2.0 реализована работа с потоками, в 2.2 помимо этого появился DBD Framework (SQL Database API).

> В 2.0 реализована работа с потоками, в 2.2 помимо этого появился DBD Framework (SQL Database API).

Я не виже принципиальной разницы при работе с MySQL через PHP. Все равно будет создаваться одно соединение для каждой php/apache instance. Вот скажите, после исчерпания ожидания KeepAlive, Apache2/mod_php закроет соединение с базой сам или база так и будет ждать пока wait_timeout не истечет? Я не держу Apache 2 на серверах за ненадобностью, поэтому провериь самому затруднительно.

Еще раз. Пойнт в том, что работая из под Java Server и используя модель обращений PHP/MySQL (Чистый JSP/Oracle)(т.е. новый коннект на каждый запрос, единственно нормально работающую по вашим же словам) мы естественно будем терять на подключениях к базе через JDBC. Поэтому такое сравнение не имеет смысла, так как ЛЮБОЕ приложение сложнее HelloWorld в J2EE использует connection pool.

Можно долго спорить, что лучше - pg или mysql, но пока мне кто нибуде не объяснит откуда взялось вот это - я обратно на мускуль не перелезу.

select distinct stamp_inserted from iptraffic_2006_06 order by stamp_inserted;


+---------------------+
| 2006-06-22 00:00:00 |
| 2006-06-23 00:00:00 |
| 2006-06-24 00:00:00 |
| 2006-06-25 00:00:00 |
| 2006-06-26 00:00:00 |
| 2006-06-27 00:00:00 |
| 2006-06-28 00:00:00 |
| 2006-06-29 00:00:00 |
| 2006-06-30 00:00:00 |
| 5510-70-02 70:74:16 |
| 5667-69-43 03:93:60 |
| |442-99-81 00:43:52 |
| ┌*.+-0'-*' 39:01:55 |
| .(+-,(-,( 53:95:52 |
| L)-+-.+-(- 30:36:16 |
| └927-92-13 44:16:00 |
| g.//-/)-+( 96:30:08 |
+---------------------+

Да и к триггерам я привык...

> Однако как видно на графике, при нагрузке до 60 параллельных соединений оно проигрывает обычному методу доступа к базе, а после этого - лишь незначительно опережает.

вы не поняли и сравнили не те графики: To simulate web applications I also ran another benchmark by just adding -C option to pgbench. This makes pgbench connect to pgpool or PostgreSQL everytime each transaction starts("without pgpool(no persistent connection)" and "with pgpool(no persistent connection)" in the above graph shows the result. The ability to cache the connection makes pgpool faster than ordinary PostgreSQL despite the replication overhead of pgpool.

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

> Неясно кстати, будет ли вообще преимущество на реальных преложениях - т.е куча процессов php/apache работающих с разными хостами, каждый имеет свой connection к базе и т.д...

вы еще раз не поняли php/apache работает только с одним хостом на котором стоит pgpool, никаких "долго живущих" соединенией на этом участке нет

> |442-99-81 00:43:52 | > | ┌*.+-0'-*' 39:01:55 | > | .(+-,(-,( 53:95:52 | > | L)-+-.+-(- 30:36:16 | > | └927-92-13 44:16:00 | > | g.//-/)-+( 96:30:08 |

дико смешно :) Раскажите как вы это сделали. У меня есть много друзей программистов, а к первому апрелю еще не придумал не одной шутки.