Памятка евангелиста PostgreSQL: критикуем MySQL ещё грамотнее
Со времени предыдущей публикации дорогая редакция получила большое количество отзывов. Большинство из них были позитивными, что несомненно укрепляет веру дорогой редакции в человечество. Поступило и несколько серьёзных дополнений в виде критических замечаний о 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 была одним из приоритетов. Просто скажите наркотикам MyISAM нет, все её проблемы не стоят каких-то скромных бонусов в производительности.
«А вот есть такой доклад и такая статья, где доказывают, что MySQL — это путь в никуда»
Я знаю, спасибо. Обзор репликации в целом и доклада/статьи в частности должен был выйти вместо данной публикации, но у меня меньше времени, чем хотелось бы. Всё будет, как обещал.
И пара новых мифов, которые добавили в комментариях.
«В MySQL проприетарщина!»
Сказал это тот самый человек, который якобы никогда никаких мифов о MySQL не придумывает и не распространяет. MySQL — это бесплатный проект под свободной лицензией. А речь судя по всему о MySQL Enterprise. Я вижу практически прямое соответствие между MySQL Enterprise и продуктами EnterpriseDB. Но «проприетарным» от этого PostgreSQL никто не называет.
«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 решение появилось ещё раньше.
Подводя итог, я не вижу в таких вещах поводов для типичных выводов, которые из них делают. Если кто-то считает, что в других СУБД подобных вещей нет, то у меня плохие новости. Раз мы здесь разговариваем в контексте PostgreSQL, можете поискать по ключевым словам «postgresql gotchas», там попадаются забавные вещи.
Если попытаться это всё обобщить и сформулировать грамотно, то я бы сказал так. В MySQL соответствие SQL стандартам никогда не было приоритетом, и общее соответствие ниже, чем во многих других СУБД, включая PostgreSQL, где соответствие стандартам является одним из главных приоритетов. Но любят MySQL не за это, и об этом позже.
Я всё ещё собираюсь написать отдельные публикации по репликации и сравнению MySQL с PostgreSQL с точки зрения MySQL пользователя. Но перед этим хотелось бы закрыть тему критики MySQL со стороны PostgreSQL сообщества. Это важно потому, что такие публикации ожидаемо вызовут шквал комментариев в стиле «нет коммьюнити и делит на ноль втихую!». Чтобы не отвечать много раз, удобнее собрать все ответы в одном месте. Спасибо всем за комментарии, надеюсь, ничего не упустил.
