тест скорости работы различных БД

[Yurik]

IMHO такая ситуация с MySQL сложилась исторически. Оракл давно имел большинство своей функциональности и только сравнительно недавно в MySQL (версии 4.0 и 4.1) появилась многая недостающая функциональность, и это при том что версии 4.х до сих пор бета, альфа и большинство людей все еще используют версии 3.23.х

* Secure connections (with SSL).
* A new query cache to cache results from identical SELECT queries.
* The InnoDB table type is now included in the standard binaries, adding transactions, row-level locking, and foreign keys.
* UNION syntax in `SELECT'
* Multi-table `DELETE' statements
* Character sets to be defined per column, table and database.
* Unicode (UTF8) support.
* Subqueries: `SELECT * from t1 where t1.a=(SELECT t2.b FROM t2)'.
* Derived tables: `SELECT a from t1, (select * from t2) WHERE t1.a=t2.a'
* Foreign keys for `MyISAM' tables, including cascading delete.
* ROLLUP' and `CUBE' OLAP (Online Analytical Processing) grouping options for data warehousing applications.

Если они еще сделают нормальные форматы дат (2003-02-31 ? ), добавят тригеры и хранимые процедуры (5.0), то преимуществ Оракла не останется. А это обещает быть очень скоро.

Что пока оставляет мускул позади, так

We are currently not targeting ... clustered databases

что оставляет его в стороне для в самом деле больших проектов.

>Это что за зверь?

MySQL Server, in almost all cases, allows you to resolve potential problems by including simple checks before updates and by running simple scripts that check the databases for inconsistencies and automatically repair or warn if such an inconsistency occurs. Note that just by using the MySQL log or even adding one extra log, one can normally fix tables perfectly with no data integrity loss.
More often than not, fatal transactional updates can be rewritten to be atomic. Generally speaking, all integrity problems that transactions solve can be one with `LOCK TABLES' or atomic updates, ensuring that you never will get an automatic abort from the database, which is a common problem with transactional databases

 

[tony2001]

>и это при том что версии 4.х до сих пор бета, альфа
4.0.12 - production release

>преимуществ Оракла не останется. А это обещает быть очень скоро.
я не разделяю оптимизм ТАКОГО уровня.
каждому своё.
второй Оракл не нужен - уже один есть.

 

[young]

второй Оракл не нужен - уже один есть.

Факт.

 

[Sad Spirit]

Yurik, всё же рекомендую поучить теорию реляционных СУБД не по мануалу MySQL, а по какой-нибудь толстой книжке (всегда советую Дейта "Введение в системы баз данных"). Тогда ты поймёшь, почему у разработчиков MySQL, забивших с начала на "правильную" реализацию в пользу т.н. "быстрой" так тяжело щас лепится из... эээ... удобрений конфетка и почему MySQL'у не то что до Оракла, до текущей функциональности свободных СУБД как до Китая... эээ... пешком.

 

[Yurik]

Алексей, по-моему твои комментарии тут неуместны, сугубо как лица "заинтересованного" в свободных СУБД (понятное дело не MySQL)

 

[Sad Spirit]

Автор оригинала: Yurik
Алексей, по-моему твои комментарии тут неуместны

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

 

[Yurik]

>не надо ......
ого-го, теперь это так называется...

>xотя я уже и начал сомневаться
ты не поверишь, но уже половину прочитал

 

[Sad Spirit]

Автор оригинала: Yurik
>не надо ......
ого-го, теперь это так называется...

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

>xотя я уже и начал сомневаться
ты не поверишь, но уже половину прочитал

Супер. Тогда с точки зрения теории объясни, почему приведённая тобой цитата

MySQL Server, in almost all cases, allows you to resolve potential problems by including simple checks before updates and by running simple scripts that check the databases for inconsistencies and automatically repair or warn if such an inconsistency occurs. Note that just by using the MySQL log or even adding one extra log, one can normally fix tables perfectly with no data integrity loss.
More often than not, fatal transactional updates can be rewritten to be atomic. Generally speaking, all integrity problems that transactions solve can be one with `LOCK TABLES' or atomic updates, ensuring that you never will get an automatic abort from the database, which is a common problem with transactional databases

является полнейшей лапшой на уши?

 

[Yurik]

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

>объясни почему является лапшой
Хорошо, я согласен в том что сравнивать Oracle и MySQL в реализации MyISAM совсем неуместно. Но речь изначально (в приведенных тестах) шла о InnoDB.

Я согласен, что проявил себя в качестве тупоголового защитника мускула (4-го), но я все-таки хочу добиться конкретных аргументов в пользу Оракл. Сам я его не пользовал, и если попробую, то нескоро (я имею ввиду соотв. образом настроенный оракл на соотв. железе).
Поэтому хочу услышать мол той и той полезной оракловской функции нету в мускуле, при таких-то нагрузках на такой-то платформе мускул вылетает, а оракл - нет.
По крайней мере, в приведенных тестах не видно отличия в производительности Оракл9 и Мускул4.

Кстати, что-то сегодня часто вылетал мускул этого форума с сообщением Cant create socket (UNIX).

 

[Screjet]

вероятно "Can't connect.."
Видать мускул настроен по дефолту на 100 коннектов.

 

[tony2001]

>Поэтому хочу услышать мол той и той полезной оракловской функции нету в мускуле
заканчивайте бесполезную дискуссию.
MySQL не будет Ораклом никогда.
просто потому, что он изначально не Оракл.
понятие "полезность" очень субъективное и спорить о отсутствии или присутствии "полезных" фич просто глупо.
впрочем, сравнивать Оракл и MySQL не намного умнее.

 

[Frutik]

есть прекрасна украинская пословица имхо подходящая к даному топику: "приємно було побалакати з розумною людиною... а от часу жалко..."

 

[Sad Spirit]

Автор оригинала: tony2001
спорить о отсутствии или присутствии "полезных" фич просто глупо.

естественно, особенно если оппонент заявляет, что этими фичами пользоваться не умеет.

Притча: недавно с удивлением узнал, что Postgres в дикой стране Японии очень популярен, а вот MySQL практически не используется. Причина проста: когда началась эта мода на использование РСУБД в какестве затычки в каждой бочке (~1998), в MySQL не было одной бесполезной для Yurik'а фичи, а в Postgres'е --- была. Фича такая: хранение текста в многобайтовых кодировках, в частности на японском языке. Дальше пошло по нарастающей.

Автор оригинала: Yurik
Возможно я слишком грубо сказал что когда фан постгре не любит мускул, и в качестве аргументов говорит что это "китайские удобрения", то это и так понятно.

Я не могу любить/не любить "мускул" --- последовательность байт на диске. Но мне очень не нравится модель поведения MySQL AB и части MySQL community, я считаю что она вредит всему движению Free Software/Open Source.

Автор оригинала: Yurik
По крайней мере, в приведенных тестах не видно отличия в производительности Оракл9 и Мускул4.

мысль для обдумывания: если покупается база за несколько десятков килобаксов, то будут ли для неё покупать дешёвое "обычное" железо, или сервер тоже будет стоить десятки килобаксов?

 

[tony2001]

>естественно, особенно если оппонент заявляет, что этими фичами пользоваться не умеет.
не "особенно", а вообще.
в принципе.
то есть совсем бесмыссленно =)

>Но мне очень не нравится модель поведения MySQL AB и части
>MySQL community, я считаю что она вредит всему движению
>Free Software/Open Source.
вот здесь интересно.
?

 

[Sad Spirit]

Автор оригинала: tony2001
>Но мне очень не нравится модель поведения MySQL AB и части
>MySQL community, я считаю что она вредит всему движению
>Free Software/Open Source.
вот здесь интересно.
?

Benchmarketing, vaporware, демагогия.

Выдающийся пример --- любимый пункт в мануале (!) How MySQL Compares to PostgreSQL. До такого вроде бы ещё никто не опускался. How KDE compares to GNOME, How Emacs compares to vim слабо в соответствующих мануалах представить? ;

 

[ONK]

Я свободно могу представить себе ссылки на сравнительные тесты с конкурентами, особенно если эти тесты подчёркивают реальные или мнимые преймущества . Это обычное дело.

Про стратегию разработки я молчу, тут вопрос тонкий, а всё остально вполне разумно. -)

 

[Sad Spirit]

Автор оригинала: ONK
а всё остально вполне разумно. -)

В сети есть и ответ на это, правда старый, времён Pg 7.1

Проблема с этим сравнением не в том, что оно есть, а в том, что там как раз три перечисленных мной проблемы:

• benchmarketing (мы быстрее потому, что мы сами так говорим!)
• vaporware (в нашей версии 5.0 у нас будут во-о-о-от такие фичи). при этом у конкурента они были две версии назад.
• демагогия: свои недостатки представлются как достоинства

 

[Screjet]

Автор оригинала: Sad Spirit
Выдающийся пример --- любимый пункт в мануале (!) How MySQL Compares to PostgreSQL. До такого вроде бы ещё никто не опускался.

Наоборот.
Вроде никто еще до такого не подымался

"Прежде всего хотелось бы отметить, что PostgreSQL и MySQL являются широко используемыми программными продуктами, которые разрабатывались с разными целями (хотя создатели обоих и стремятся довести их до полной совместимости со стандартом ANSI SQL). Это значит, что для решения одних задач больше подходит MySQL, для других же - PostgreSQL. Выбирая СУБД, проверьте, соответствуют ли ее возможности требованиям, предъявляемым решаемой задачей. Если требуется максимальная скорость работы, лучше всего, вероятно, будет остановить свой выбор на MySQL Server. Если же вам необходимы дополнительные возможности, имеющиеся только у PostgreSQL, этой СУБД и стоит пользоваться. "
(с) http://www.mysql.com/doc/ru/Compare_PostgreSQL.html

 

[tony2001]

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

We have many times asked the PostgreSQL developers and some PostgreSQL users to help us extend this benchmark to make it the definitive benchmark for databases, but unfortunately we haven't gotten any feedback for this.

>Выдающийся пример --- любимый пункт в мануале
достаточно корректно написана глава, которую бы надо в FAQ переместить.

 

[Sad Spirit]

Автор оригинала: tony2001
>Benchmarketing
однако, никто не смог и опровергнуть результатов, так?

Почему? А тесты Tim Perdue, а тесты GreatBridge? То-то там по поводу этих тестов такое обиженное сопение наблюдается.

Автор оригинала: Screjet
Наоборот.
Вроде никто еще до такого не подымался

"Прежде всего хотелось бы отметить, что PostgreSQL и MySQL являются широко используемыми программными продуктами, которые разрабатывались с разными целями (хотя создатели обоих и стремятся довести их до полной совместимости со стандартом ANSI SQL). Это значит, что для решения одних задач больше подходит MySQL, для других же - PostgreSQL. Выбирая СУБД, проверьте, соответствуют ли ее возможности требованиям, предъявляемым решаемой задачей. Если требуется максимальная скорость работы, лучше всего, вероятно, будет остановить свой выбор на MySQL Server. Если же вам необходимы дополнительные возможности, имеющиеся только у PostgreSQL, этой СУБД и стоит пользоваться. "
(с) http://www.mysql.com/doc/ru/Compare_PostgreSQL.html

Ишшо раз: если бы на этой фразе они остановились, я бы сказал: "молодцы". Но Остапа несло. (c)