Со времени предыдущей публикации дорогая редакция получила большое количество отзывов. Большинство из них были позитивными, что несомненно укрепляет веру дорогой редакции в человечество. Поступило и несколько серьёзных дополнений в виде критических замечаний о MySQL, о которых я либо забыл, либо никогда не слышал. Что и привело к созданию второй части, которая на самом деле является дополнением к первой и изначально не входила в мои планы.
Итак, продолжаем разбор типичных заблуждений о MySQL в рамках культурного обмена и осеннего обострения. Для начала несколько критических отзывов о первой части.
«Длинный список использующих MySQL компаний ничего не значит, потому что они используют MySQL как key-value хранилище»
Иногда добавляют, что слышали это только про Facebook/Twitter, а про остальные не в курсе. Кто-то говорит, что не используют JOIN-ы. Но источник никто не указывает.
Во-первых, даже если бы это было так, это бы ничего не меняло. Этот краткий и далеко не полный список компаний я привёл только для того, чтобы показать: нравится это кому-то или нет, но MySQL — самая популярная СУБД в крупнейших веб-компаниях, поэтому legacy технологией её можно называть только живя в какой-то своей параллельной реальности.
Во-вторых, нужно понимать, что речь идёт о полутора десятке огромных компаний с десятками и сотнями внутренних сервисов, в каждом из которых свои структуры и объёмы данных, требования по времени отклика, распределение по чтению/записи и т.д. Не в каждом из этих сервисов используется MySQL, но утверждать, что в каждом случае MySQL используется исключительно в качестве key-value хранилища — как минимум наивно.
Проще всего с Wikipedia — исходный код MediaWiki открыт, каждый может посмотреть на типы запросов самостоятельно. К тому же сотрудники Wikipedia рассказывают об инфраструктуре подробнее, чем представители других компаний.
Возвращаясь к Facebook, какие-то наиболее нагруженные сервисы несомненно работают как key-value. Просто потому, что данные шардированы по тысячам серверов, а перед СУБД стоит key-value кэш, что несколько ограничивает применение агрегации, JOIN-ов и т.д. Но сервисов у Facebook много, и требования к ним разные. Здесь довольно свежее описание используемых в Facebook технологий для хранения данных. Если вы найдёте там подтверждение тезиса об исключительно key-value характере использовании MySQL — дайте мне знать.
«Длинный список использующих MySQL компаний ничего не значит, потому что сейчас бы они MySQL не выбрали»
Никаких обоснований, естественно, не приводится, но я попробую сам. В этом была бы своя логика, если бы речь шла о статичных компаниях, которые не растут, где не появляются новые сервисы и новые задачи по хранению и обработке данных. Или о небольших компаниях, где ограничены ресурсы, а значит лучшая СУБД — это та, с которой «знакома команда». Возвращаясь к пресловутому Facebook, ни то ни другое к нему не относится. Там нет никаких «религиозных» предубеждений, разные технологии используются исходя из конкретных технических задач. Бывает и так, что разрабатываются новые технологии, потому что ни одна из существующих не подходит под требования. Примеры: Cassandra, Presto, Scuba.
Если пытаться обобщить причины, по которым компании выбирают и продолжают выбирать MySQL, то я не открою Америку, если скажу, что MySQL используют как надёжное и масштабируемое хранилище для OLTP нагрузок (с key-value как частный случай). Я старательно избегаю критики PostgreSQL, поэтому и здесь многозначительно промолчу — будет отдельная публикация.
А если кто-то говорит, что существует волшебная СУБД на все случаи жизни, купите ему леденец.
«MyISAM на самом деле актуален, потому что ...»
Кто-то говорит, что «бытовые» (кстати что это?) CMS используют MyISAM. Кто-то говорит, что системные таблицы до сих пор в MyISAM (и это отчасти верно даже для 5.7, хотя были надежды, что это исправят). Кто-то использует MyISAM как хранилище для временных / append-only данных вроде логов.
Я могу только повторить сам себя: MyISAM это действительно legacy в полном смысле этого слова. Ограничения всем известны, код не развивается, и вряд ли даже поддерживается, и есть полноценная замена. Если кто-то где-то ещё находит ей применение — это прекрасно, но я бы всё-таки посоветовал посмотреть на InnoDB. Особенно в 5.7, где производительность в сравнении с MyISAM была одним из приоритетов. Просто скажите
«А вот есть такой доклад и такая статья, где доказывают, что MySQL — это путь в никуда»
Я знаю, спасибо. Обзор репликации в целом и доклада/статьи в частности должен был выйти вместо данной публикации, но у меня меньше времени, чем хотелось бы. Всё будет, как обещал.
И пара новых мифов, которые добавили в комментариях.
«В MySQL проприетарщина!»
Сказал это тот самый человек, который якобы никогда никаких мифов о MySQL не придумывает и не распространяет. MySQL — это бесплатный проект под свободной лицензией. А речь судя по всему о MySQL Enterprise. Я вижу практически прямое соответствие между MySQL Enterprise и продуктами EnterpriseDB. Но «проприетарным» от этого PostgreSQL никто не называет.
Обновлено 16.11.2015: По немногочисленным, но настойчивым просьбам в комментариях добавляю следующий текст:
Да, лицензия GPL, под которой распространяется MySQL не допускает смену лицензии, в том числе на проприетарную. Поэтому закрытых форков нет. Oracle, как владелец копирайта, лицензию может менять по своему усмотрению.
BSD лицензия, под которой распространяется PostgreSQL, допускает смену лицензии. Поэтому много проприетарных форков.
Обновлено 12.11.2016: Как я и предсказывал в комментариях год назад, компания Postgres Pro тихо и незаметно выпустила свой собственный проприетарный форк . Разговоры о «проприетарности» MySQL как-то сами собой сошли на нет.
«MySQL не нужен, потому что <смешной пример из интернета>»
Обычно идёт ссылка на эту статью, которая, наверное, составляет самое серьёзное дополнение из всех прочитанных комментариев к предыдущей статье. Сама статья, на мой взгляд, представляет из себя пример грамотной критики MySQL без «евангелистских» выводов типа «MySQL — путь в никуда», «MySQL не нужен», «очевидно ущербная СУБД» и прочего выдавания желаемого за действительное. Человек перечисляет примеры странного или неинтуитивного поведения. Половина из них основана на одном простом факте: в MySQL есть неявное приведение типов, которое распространяется не только на операторы, но и на функции. Все примеры с LEAST() из упомянутой статьи эксплуатируют этот единственный факт. Туда же относится популярный пример с SELECT 0 = 'Sean'.
Что может выглядеть странно для человека, который чаще имеет дело со строгой типизацией (для меня, например, выглядит странно), но абсолютно естественно для программистов на JavaScript, PHP, Perl и прочих языков из мира web. Для этих языков можно привести много похожих примеров, и это никого особо не удивляет.
По остальным примерам из упомянутой статьи:
— примеры с ENUM: да, странное, хоть и документированное поведение. Но вообще есть гораздо более серьёзные причины не использовать ENUM, которые относятся к любой СУБД.
— примеры с UNION и INNER JOIN — да, с парсером куча проблем, и здесь никаких возражений. О планах переписать парсер в MySQL я слышу уже много лет, и работа наконец началась, что не может не радовать.
— пример с bug #27877: печально известный нюанс с правилами сортировки для немецкого языка и кучей проблем с совместимостью и апгрейдами. Но решение для этой проблемы существует уже 3 года как в основном MySQL, а в MariaDB и Percona Server решение появилось ещё раньше.
Обновлено 24.03.2016: А вот свежий пример не менее серьёзной проблемы с кодировками в PostgreSQL.
Подводя итог, я не вижу в таких вещах поводов для типичных выводов, которые из них делают. Если кто-то считает, что в других СУБД подобных вещей нет, то у меня плохие новости. Раз мы здесь разговариваем в контексте PostgreSQL, можете поискать по ключевым словам «postgresql gotchas», там попадаются забавные вещи.
Если попытаться это всё обобщить и сформулировать грамотно, то я бы сказал так. В MySQL соответствие SQL стандартам никогда не было приоритетом, и общее соответствие ниже, чем во многих других СУБД, включая PostgreSQL, где соответствие стандартам является одним из главных приоритетов. Но любят MySQL не за это, и об этом позже.
Обновлено 22.11.2015: Бывают и исключения из общего правила, т.е. случаи, где MySQL лучше поддерживает стандарт(ы), чем PostgreSQL. Статья на тему.
Заключение
Я всё ещё собираюсь написать отдельные публикации по репликации и сравнению MySQL с PostgreSQL с точки зрения MySQL пользователя. Но перед этим хотелось бы закрыть тему критики MySQL со стороны PostgreSQL сообщества. Это важно потому, что такие публикации ожидаемо вызовут шквал комментариев в стиле «нет коммьюнити и делит на ноль втихую!». Чтобы не отвечать много раз, удобнее собрать все ответы в одном месте. Спасибо всем за комментарии, надеюсь, ничего не упустил.