Являются ли проблемы с согласованностью / потерей данных / оптимизацией запросов, о которых я читал, «такими плохими»?

Question

Поскольку я изучал различия между Postgres и MySQL, меня поразило, что, если верить тому, что я читаю, MySQL должен быть (отказ от ответственности: читая оставшуюся часть этого предложения, вы соглашаетесь читать следующий абзац также) посмешище мира RMDB: по умолчанию он не использует ACID, сеть изобилует историями о потере данных, связанных с MySQL, и всеми учетными записями, а оптимизатор запросов - шутка.

Но, похоже, все это не имеет значения. Нетрудно сказать, что MySQL имеет примерно в миллион раз больше ажиотажа, чем Postgres (это LA M P, а не LAPP), большие установки MySQL не являются неслыханными (LJ? Digg?), И я не заметил падения популярности MySQL.

Это заставляет меня задуматься: действительно ли эти "проблемы" с MySQL настолько плохи?

Итак, если вы использовали MySQL для достаточно большого проекта **, каким был ваш опыт? Вы также использовали Postgres ? Как это было хуже? Как было лучше?

*: [необходима цитата]
**: я хорошо знаю, что для «мелких вещей» (блоги, что у вас есть), MySQL (наряду с практически любой другой RDB) просто отлично.

Answer 1

Поскольку он помечен [субъективно], я буду субъективен. Для меня это мелочи. PostgreSQL более дружественен к разработчикам и позволяет легко делать правильные действия в отношении целостности данных по умолчанию.

• Если вы дадите MySQL неверный тип, он неявно преобразует его, даже если преобразование неверно. PostgreSQL будет жаловаться.
• EXPLAIN в PostgeSQL гораздо полезнее, чем в MySQL. Это дает вам точный план структурированных запросов. Какой тип алгоритма он будет использовать, сколько стоит каждый шаг и т. Д. Это означает, что если оптимизатор запросов в MySQL не сделает то, что вы думаете, у вас будет трудное время для его отладки.
• Если вы когда-нибудь писали что-то более сложное на языке хранимых процедур MySQL, вы будете знать, насколько это больно. PL / pgSQL на самом деле хороший язык + вы можете использовать много других языков.
• В MySQL нет последовательностей, поэтому, если они вам нужны, вы должны выполнить свою собственную. Большинство людей сделают это неправильно, и в их коде есть условия гонки.
• PostgreSQL предоставляет разработчикам большую часть своих внутренних типов блокировок. Если вам нужно заблокировать свой стол особым образом, вы можете сделать это.
• Все программируется в PostgreSQL. Например, если вам нужен собственный тип данных для некоторых конкретных данных, вы можете добавить его. Вы можете добавить приведения и операторы для типов данных. Вероятно, не стоит усилий для небольших проектов, но это лучше, чем хранить вещи в виде строк.
• PostgreSQL добавляет каждое действие, включая изменения DDL в транзакцию, в отличие от MySQL. Если у вас есть скрипт преобразования, который создает / удаляет таблицы, BEGIN / END не поможет вам в MySQL поддерживать его в согласованном состоянии.

Это не означает, что невозможно написать хорошие приложения для баз данных с MySQL, просто требуется больше усилий.

Answer 2

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

Если используется правильно , значит, оно совместимо с ACID. Если используется неправильно, это не так. Беда в том, что люди, похоже, считают, что хорошо иметь соответствие требованиям ACID.

В действительности ACID часто является врагом производительности (особенно D для долговечности). Слегка уменьшив долговечность, мы обычно получаем очень большое повышение производительности.

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

Answer 3

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

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

Другим моментом является то, что MySQL только недавно научился быть «настоящей базой данных», в то время как почти все конкурирующие продукты начали жизнь с полным ACID.

В MySQL были проблемы практически со всеми аспектами ACID. Большинство из них ушли или могут быть настроены, но вам придется проверить каждый из них. Например, проблема с атомарностью заключается в том, что вы не заметите их, пока не загрузите свою систему под большой нагрузкой (что, к сожалению, часто совпадает с тем, что она является производственной системой).

Итак, мое резюме будет таким: MySQL способен работать в этой среде, но это требует работы. И путь, который потребовался, чтобы добраться до этой точки, стоил ему немало очков в зоне доверия.

Answer 4

действительно ли эти "проблемы" с MySQL настолько плохи?

На самом деле, боль, которую MySQL причинит вам, может варьироваться от умеренной до безумной, и многое из этого зависит от MyISAM.

Я считаю, что хорошее эмпирическое правило таково:

вы создаете резервные копии таблиц MyISAM?

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

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

Если вы сделаете много одновременных обновлений таблиц MyISAM, то вы пройдете через стадию мира вреда: когда нагрузка достигнет определенного порога, вы обречены. Конечно, считыватели блокируют средства записи, которые блокируют устройства чтения, которые блокируют средства записи в очереди и т. Д., Поэтому производительность плохая, загрузка avg достигает 200, а ваш ящик обнуляется, но я также мог последовательно разбивать таблицы MyISAM в тесте, который я написал 2 года назад просто ударяя их со слишком большой нагрузкой. Произошли случайные данные, иногда сбой mysql при выборе или извергая случайные ошибки.

Итак, если вы избегаете MyISAM, как чумы, проблемы с MySQL не так уж и плохи. InnoDB надежен. Тем не менее, как правило, я считаю, что он уступает Postgres, который работает быстрее и имеет намного меньше ошибок, а работа становится проще и быстрее.

Answer 5

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

В общем, почти все проблемы MySQL можно решить с хорошей дисциплиной. Проблема в том, что разработчик должен знать все ошибки и обходить их. После работы с PostgreSQL или Oracle это похоже на смерть на тысячу бумажек. Вы привыкли, что вещи просто работают.

Это довольно значительная проблема в тех типах вещей, над которыми я работал. Сложные схемы со сложными запросами и большим количеством данных. сжатые сроки с небольшим временем на проектирование производительности означают, что важно получать постоянно разумную производительность без необходимости вручную оптимизировать запросы. Хороший оптимизатор на основе затрат - это почти требование. Объедините это с большим количеством аутсорсинга с командами разработчиков, у которых нет опыта, чтобы вовремя поймать все ошибки, и небольшие проблемы обостряются до больших проблем с QA. Попадание в MySQL безмолвного повреждения данных при работе - это то, что действительно пугает меня. Я возьму любые декларативные ограничения на уровне базы данных, которые я могу получить, по крайней мере, для некоторой сети безопасности, к сожалению, MySQL не справляется с этим.

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

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

Answer 6

Мы используем MySQL в некоторых приложениях - и он довольно неплохо работает. В более новых проектах мы используем движок InnoDB - и хотя он может работать медленнее, чем движок по умолчанию, он работает хорошо.
Прямо сейчас мы используем маппер ORM - и поэтому большая часть сложности скрыта за маппером ORM (и работает хорошо).

Я думаю, что инфраструктура (инструменты и информация) является одним из больших плюсов MySQL: мы используем действительно хорошие инструменты: Toad для MySQL и MySQL Administrator .

Хотя я должен признать, что на прошлой неделе у меня был шокирующий опыт, когда я помогал другу с оператором SQL и соответствующим подзапросом, почти остановив его сервер MySQL - но с хитростью заключив его в другой запрос - он работал очень хорошо.
Это ничего, что ДЕЙСТВИТЕЛЬНО меня шокирует - потому что я использовал другие системы БД, которые стоят больших денег (я смотрю на вас - DB2), - и у них были другие вещи, которые можно обойти. (возможно, не так радикально, но все же вам пришлось оптимизировать их).

Answer 7

Нет, проблемы, о которых вы говорите, не имеют большого значения. См. Google и Facebook как два примера компаний, которые используют MySQL для выполнения задач Herculean, о которых вы только мечтаете.

Я использую следующие правила при запуске MySQL, чтобы предотвратить головные боли:

1. Делайте ежедневные, еженедельные, ежемесячные снимки базы данных. Чаще всего проблемы, с которыми вы столкнетесь, не имеют ничего общего с MySQL, вместо этого это запущенный разработчик:

   УДАЛИТЬ ИЗ mytable; # Где ГДЕ?

2. Использовать InnoDB по умолчанию, единственная причина использования MyISAM - полнотекстовый поиск.

3. Получите схему базы данных под управлением исходного кода.