MySQL rant

Из интервью MySQL CEO для Guy Kawasaki:

We focus on the new applications and services that are being built for the online world: Web2.0, SaaS, and SOA but also new forms of datawarehouses and business apps. Our customers look for reliability, performance, scalability, and ease of deployment.

Лично я пришел к выводу, что мне не нужна программа, которая выдает неправильный ответ очень быстро. Поэтому и заказал на Амазоне книгу Beginning Databases with PostgreSQL.

update: удалил фрагмент цитаты который я по невнимательности приплел из комментариев.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



23 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Впрочем, не в первый раз. Одно время Макс пытался пройтись по больной мозоли vim vs emacs, но меня тогда не зацепило. И еще много таких тем есть. Правда, при всем при том ЛОР в подобных вопросах вне конкуренции: -).

Макс, ты нашёл верный способ поднять комментируемость постов на сайте; -)

В общем, для тех, кто желает отдохнуть душой: http://www.linux.org.ru/view-m...Кстати, по поводу постгрессовских ANALYZE и PREPARE — они вполне могут спасти ситуацию. Может, таки проведем еще один забег, но с полноценным тюнингом от фанатов соответствующих СУБД? В рамках MySQL-PG-Orackle? Кто берется помочь?

Еще не стоит забывать, что mysql блокировщик в то время как pg и oracle версионники. На разных задачах — разные плюсы и минусы.

Кстати, из обсуждение вышеприведенного бенчмарка на ЛОРе:

Я, кстати, делал сравнение производительности MySQL и PostgreSQL, так вот, производительность в тестах различалась не более чем на 10 — 15%, причем в обе стороны.О чем говорят результаты моего теста? Да ни о чем! Потому, что это были моиусловия_эксплуатации_ в моем проекте. В других проектах может выиграть MySQL — там, где мало таблиц и почти нет связей между ними. Может выиграть и Постгрес — там, где надо держать бизнес-логику в базе, а не снаружи

Так что, пора завязывать с этими священными войнами...

PostgreSQL сложнее, её нужно уметь оптимизировать и уметь правильно строить базы данных.

"Вы не любите кошек? Вы просто не умеете их готовить! «Вообще говоря, это называется «жертвовать скоростью разработки и стоимостью поддержки».Так что, это опять же банальный вопрос выбора: что важнее — стоимость сопровождения и производительность с одной стороны или высокая надежность — с другой.

Издание «C’T magazine» провел соревнование среди наиболее популярных open source СУБД. В качестве теста было предложено обслуживание клиентов в интернет-магазине.Результаты участников: MySQL5/PHP: 3664 заказов в минутуDB2/Java: 1537Oracle/Java: 1412PostgreSQL/PHP: 120http://www.mysqlperformanceblo.../

2Вика: пойми меня правильно — очень приятно видеть среди нас девушку, сталкивающуюся с MySQL:]

И для этого мне не нужны какие-то тесты, которые доказывают что MySQL быстрее.

Смешной подход.

Да ладно вам... Просто MySQL в режиме MyISAM нужно рассматривать не в контексте СУБД, а в контексте небезопасных электронных таблиц:)

> А если я, скажем хочу ссылочную целостность и fulltext? Тогда вам придется выбирать;) > хочу заметить что «rant» можно перевести как «возможность спустить пар, не отвечая за свои слова».Гм. Ну если все это было написано только для того, чтобы показать пальчиком «мальчик для битья находится тут» то нивапрос...

Кроме того наличие разлитные типов storage engines одни из которых поддерживают транзакции и внешние ключи, другие нет, третьи кластерные, четвертые в памяти и т.д. позволяют тебе выбрать что ты хочешь — с транзакциями и внешними ключами, но более медленное или без всего этого, но более шустрое.

А если я, скажем хочу ссылочную целостность и fulltext? Тем более что СЦ не ограничивается просто поддержкой внешних ключей.Принимая упреки по качеству поста, хочу заметить что «rant» можно перевести как «возможность спустить пар, не отвечая за свои слова».; -)

> PostgreSQL сложнее, её нужно уметь оптимизировать и уметь правильно строить базы данных.mkdir, вы так говорите будто при использовании других СУБД нет необходимости оптимизировать и правильно проектировать базу;)

PostgreSQL делает по скорости MySQL очень серьёзно. И по надёжности тоже.И для этого мне не нужны какие-то тесты, которые доказывают что MySQL быстрее. PostgreSQL сложнее, её нужно уметь оптимизировать и уметь правильно строить базы данных.Тогда MySQL остаётся вне конкуренции.

И еще, в пользу PG могу упомянуть EnterpriseDB — открытую СУБД на основе Postgres, мимикрирующую под Oracle. То есть, возможно начать разработку на PG, а по мере появления финансовых возможностей мигрировать на Oracle. Правда, сколько нужно пилить напильником при миграции, я не знаю. Не исключено, что выгода не такая уж и серьезная.

Года три назад я проводил сравнительное тестирование производительности СУБД на основе некого теста. Собственно, вначале сравнивались PG (версии 7) и BDB, как типичные представители SQL-сервера и навигационной базы. Навскидку проигрыш SQL был примерно в 10 раз. Отсюда делался вывод, что SQL проще в разработке и надежнее, но проигрывает в эффективности.Потом уже чисто для себя решил прогнать через тот же тест MySQL, и оказалось, что быстродействие его сравнимо с BDB. Позже я узнал, что, собственно, само хранилище MySQL построено на движке BDB, отсюда и неудивительные результаты.Однако, в последнее время (в версиях 4 и 5) MySQL вводит альтернативные хранилища, в частности, на InnoDB. Это хранилище позволяет все упомянутое: и ссылочную целостность и транзакции. Производительность на этом движке я не проверял (равно, как и PG версии 8), однако подозреваю, что она будет заметно ниже — как-никак, бесплатных пирожных не бывает. Если интересно, могу как-нибудь попробовать.В общем, важно то, что MySQL дает возможность выбора: можешь сделать быстро и ненадежно, а можешь сделать медленно и надежно.Насчет «выдает неправильный ответ» в MySQL при переходе от тройки к четверке было замечено изменение правил округления, что сгоряча объявили багой. Однако, оказалось, что это наоборот, фича, связанная с переходом на SQL-92 в версии 4. Так что, «не считать приоритетным» и «не делать вообще» — несколько разные вещи. Кстати, представления в MySQL сделаны по одной единственной причине: не нужны. В доке прямо написано — будут сделаны, как только найдутся желающие профинансировать разработку этой фичи. Видимо, желающих профинансировать пока не нашлось.Насчет «падает база». Что в PG что MySQL мне ни разу не пришлось восстанавливаться. Единственный мой опыт перестройки индексов в MySQL был связан исключительно с переходом от версии 4 к версии 5.Насчет «навороченности PG». В версии 7 меня очень привлекала фича «наследования таблиц», что позволяет использовать ООМ при разработке модели данных. Поговаривают, что такая фича есть в Oracle (хотя, наверное, проще перечислить, чего в нем нет), но ее использование тормозится тем, что все оригинальные фичи Oracle имеют особенность работать раком в самых неожиданных ситуациях.

Max, мне кажется вы немного неправильно поняли и цитату. MySQL начиналась с маленькой, шустрой, простой СУБД, которая не поддерживала многих фич, но при этом была очень быстрой и заняла этим определенную нишу на рынке.Это совсем не значит что сейчас этих фич нет, кстати. Я с MySQL столкнулась 4, 5 года назад и тогда там уже были и транзакции и внешние ключи.Хорош этот путь развития, когда начинают с чего-то простого и потом усовершенствуют продукт, или плох мне сложно судить. С одной стороны, так легко ошибиться и зайти в тупик, т.к. для реализации новой фичи необходимо переделывать значительные куски продукта. Собственно в некоторой степени это и происходит в MySQL.С другой стороны это им позволило занять определенную нишу и люди сделали на этом бизнесс.Кроме того наличие разлитные типов storage engines одни из которых поддерживают транзакции и внешние ключи, другие нет, третьи кластерные, четвертые в памяти и т.д. позволяют тебе выбрать что ты хочешь — с транзакциями и внешними ключами, но более медленное или без всего этого, но более шустрое. И тех кому нужна скорость их не мало, вот и все.Я не собираюсь агитировать за MySQL, но мне показались некорректным как цитирование, так и выводы:)

2Вика и Malx: виноват, буду внимательнее с цитированием.Насчет "очень быстро"="выдает неправильный ответ" я намекал, например, на отсутствие ссылочной целостности или транзакций, которые открывают поле для оптимизации, но слишком дорогой ценой.

Непонятно почему указано, что это из «интервью MySQL CEO для Guy Kawasaki», если первый кусок — это цитата из комментариев, которая к самому интервью не имеет никакого отношения.Не поняла почему эти два куска процитированы рядом. Второй кусок предполагался быть подтверждением или противопоставлением комментарию? Вторую цитату можно в двух словах перефразировать как «мы будем развивать все, потому что нашим кастомерам нужен клевый продукт». Никакой особой смысловой нагрузки она не несет.Ну и наконец непонятный вывод, где почему-то «очень быстро „=“ выдает неправильный ответ».

Это была цитата одного из коментариев (самый нижний — там кажется в обратном порядке они идут).А вот про «неправильный ответ» — глупости:) Тем более читай внимательно — там говорится что оно «было добавлено позже». Т.е сейчас оно уже есть.:) Хотя да — какое-то такое странно сложившееся мнение витает вокруг, что PG — это круто надежно, но тормознуто, а mysql — это быстро легко и практично, но иногда слетает база:) Только вот мнение может уже не отвечать истине (также как и мнение что linux не имеет графического интерфейса, а только командную строку %)) Столько всякого странного вокруг можно услышать:)

Вот интересно, в комментах по ссылке эта фраза обсуждается, а в тексте её (уже?) нет...

Підписатись на коментарі