Эволюция СУБД MySQL

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

Сервер реляционных баз данных MySQL (RDBMS MySQL) за короткое время успел стать сверхпопулярной СУБД, а также незаменимой частью современного Интернета, входя в священную связку из "большой четверки" открытых web-технологий LAMP (Linux-Apache-MySQL-PHP), которая и формирует технологически почти весь современный Web. Роль баз данных в этой связке в наш насыщенный информацией век все более и более приобретает исключительный характер, и поэтому архитектура современного сайта всегда подразумевает наличие быстрого и гибкого хранилища информации, роль которого в современном интернете в большинстве случаев уготована именно MySQL.

Исторически, первая более или менее работоспособная публичная версия MySQL имела номер 3 и была выпущена в 2000 году. Эту версию можно лишь условно назвать СУБД – это была, скорее, лишь заготовка для будущего сервера БД с самой минимальной поддержкой SQL. Затем, в 2004 году после очень продолжительного тестирования и обкатки зарелизилась очень удачная и хорошо сбалансированная по функционалу и качеству кода версия 4, которая и получила самое широкое распространение в Web-проектах, создав ту самую популярность, которую проект MySQL пожинает и по сей день.

В ней впервые появились соединения, подзапросы, поддержка B- и R-деревьев, короче, тот минимум поддержки SQL, который реально позволял использовать MySQL как свободное и эффективное хранилище данных для реальных малых и средних проектов по всему миру. Ровно через год спешно была доработана и выпущена новая версия 5, которая представляет из себя уже вполне законченную и логически зрелую СУБД со всех точек зрения, содержащую в себе такие продвинутые возможности, как, например, хранимые процедуры, представления, курсоры, триггеры, транзакции и многое другое. Версия 5.1, вышедшая в 2008 году, – это дальнейшая шлифовка той же "пятерки" с добавлением планировщика событий, поддержки плагинов и расширений, хранения логов и статистики сервера в виде таблиц БД, а также многих других декоративных изменений-удобств.

По мере прихода известности и начала активного развития проекта у него стали появляться и серьёзные проблемы, качество разработки ухудшили многочисленные перепродажи и смены собственника компании-разработчика MySQL AB. Например, даже последняя версия MySQL 5.1 содержит ряд серьёзных ошибок (которые хорошо документированы и известны), приводящих к краху сервера или выдаче неверных результатов – их исправление откладывается постоянно на потом якобы в силу их серьёзной архитектурной природы. По сравнению с версией 4.1, в новых версиях серьёзно упала производительность. Короче, я бы назвал бы все это типичной проблемой роста известного проекта. На этом переходном этапе, когда смелые желания, вскруженные успехом головы и порождаемые столь быстрым развитием сложные проблемы стали опережать реальные возможности разработчиков, где-то в районе 2008-2009 годов появилось много недовольных вышеописанным положением дел, после чего стали, как грибы после дождя, появляться альтернативные форки-реинкарнации хорошо известного нам MySQL.

Из множества примеров приведу только один, зато наиболее яркий пример – это уход из Sun самого автора и создателя MySQL Майкла Вайдиниуса (Michael "Monty" Widenius) именно из-за причины чрезвычайно некачественного производственного цикла разработки MySQL, установленного в стенах Sun Microsystems, когда ещё объективно не готовую программу (кстати, предназначенную для промышленной эксплуатации) административными мерами принуждают релизить к заранее жестко установленным датам, объясняя это какими-то туманными маркетинговыми соображениями. Кроме того, по мнению Майкла Вайдиниуса, разработка должна вестись в едином открытом пространстве, без разделения исходных текстов на коммерческую и комьюнити ветки, как это сделала Sun. Так, например, в ветке MySQL 5.1 до сих пор не исправлены 20 хорошо известных критических ошибок, приводящих к краху процесса или к искажению данных.

Число критических ошибок можно смело увеличить еще на 35, если учитывать нерешенные проблемы ветки 5.0, которые, скорее всего, присутствуют и в 5.1. На фоне этого нарастающего бардака терпение Майкла лопнуло, и он решил уволиться после того, когда даже критическая ошибка, связанная со сбоем при изменении первичных ключей в режиме построчной репликации, не остановила Sun от выпуска финального "стабильного" релиза MySQL 5.1. Нужно ли говорить о том, что с переходом MySQL в собственность Oracle ситуация с разработкой только ещё больше ухудшилась? Все эти чрезвычайно деструктивные тенденции очень сильно подхлестнули творчество разработчиков этой популярной БД "на стороне". Если посмотреть ретроспективно, то 2008-2009 год – это резкий всплеск создания проектов-форков MySQL, и следует заметить, забегая чуть вперед, что многие из них оказались очень даже перспективными и успешными. Теперь давайте обзорно рассмотрим главные из них на конец 2010 года. ExtSQL

В развитии разных веток их разработчики пошли разными концептуальными путями. С одной стороны, сделана попытка наращивания ещё большей функциональности и добавления множества новых фичей – например, это проект компании Software Workshop под названием ExtSQL. В проекте параллельно ведутся две ветви разработки, базирующихся, соответственно, на кодовых ветках 4-ой и 5-ой версий оригинального MySQL. ExtSQL разрабатывался с сильным уклоном на специализированное использование в системах web-хостинга и призван решить проблемы, связанные с организацией учета потребления ресурсов. Администраторы ExtSQL получают возможность полного мониторинга активности пользователей, всех баз данных и соединений.

Например, запрос "SHOW STATISTICS select, insert FROM user HISTORY" позволит узнать число запросов "select" и "insert", совершенных пользователями за последний час. Естественно, для этого в бывшем MySQL добавлены новые команды и расширен диалект SQL, но при этом сохранена полная обратная совместимость с MySQL. Кроме поддержки своей версии MySQL, организация-разработчик Software Workshop входит в состав технического комитета INCITS H2, участвующего в развитии стандарта SQL, и активно пытается добиться расширения SQL в плане добавления возможностей для учета потребления серверных ресурсов. В целом, если говорить языком цифр, то независимое тестирование показывают, что плата за подобные надстройки над MySQL выражается в потери производительности сервера в среднем на 5% на обычных задачах и на 15-20% при интенсивной работе с реально большими базами данных. Итак, ExtSQL – это своего рода редакция "MySQL Server Advanced Hoster Edition" для особенно требовательных пользователей СУБД этого класса. Drizzle

Совершенно противоположной дорогой пошел другой популярный форк MySQL – проект Drizzle. Этот проект основан бывшим директором MySQL по архитектуре Брайаном Эйкером (Brian Aker) и представляет собой упрощенный и более быстрый вариант MySQL, в котором тщательно отобраны и удалены все ресурсоемкие и маловостребованные возможности MySQL 5. Часть из этих возможностей всё же можно реализовать через подключаемые плагины. Эта СУБД позиционируется как высокоскоростная и высоконадежная БД с поддержкой ACID-транзакций. В качестве хранилищ данных используются InnoDB и PBXT. Интересно, что весь сишный исходный код MySQL был полностью переписан на языке C++. Управление проектом находится в руках независимого сообщества.

В отличие от SQLite, Drizzle не претендует на роль встраиваемого решения и реализован в виде сервера. Архитектура Drizzle построена на основе идеи микро-ядра, в ней исповедуются максимальное упрощение структуры БД и вынос логики на сторону приложений. В частности, такой дизайн СУБД позволяет организовать обработку просто ОГРОМНОГО числа параллельных запросов, при выполнении которых в полной мере задействуются мощности современных многоядерных CPU. Как результат – Drizzl'овские пиковые показатели интенсивности обмена запросами-ответами с web-приложением завесят любой стандартный сервер MySQL 5.1, который просто захлебнётся под такой нагрузкой (тысячи или десятки тысяч сетевых соединений в случае "обычного" MySQL почти гарантированно вызывают проблемы с памятью сервера БД – см. открытые ошибки bug#26590, bug#33948, bug#49169, так что не думайте, что при такой нагрузке достаточно просто обновить железо сервера).

Кроме этого, в Drizzle дополнительно реализованы встроенные средства для разнесения данных по ключевому полю (шардинг) на кластер из нескольких машин, для создания эффективной балансировки нагрузки для по-настоящему сверхнагруженных проектов. По сравнению с MySQL, в Drizzle удалена поддержка хранимых процедур (вместо CREATE FUNCTION следует использовать связываемые объекты), триггеров, кэша запросов (query cache), представлений (view), операций GRANT и ALTER, ограничений ACL, команды SHOW, предварительно подготовленных запросов (prepared statement) и др. Прекращена поддержка малоиспользуемых типов данных из MySQL. На вопросы оппонентов, как же можно использовать БД, например, без view'ов, разработчики отвечают в том ключе, что "все те, кому действительно серьёзно нужны view'ы, уже давно сидят на PostgreSQL или Oracle, это же касается и всех других продвинутых фичей".

Да, действительно, для запуска под Drizzle, например, очень многих блоговых движков, написанных в связке с MySQL, понадобится модификация и некоторый тюнинг кода этих движков. Впрочем, как успокаивают разработчики, изменения эти невелики, и возможностей Drizzle, на самом деле, более чем достаточно для полноценного функционирования большинства популярных CMS. Кроме того, сообщество уже кастомизировало многие известные php-движки под Drizzle, что позволяет показывать их рекордную производительность на том же железе, на котором раньше крутился старый-добрый MySQL. В качестве приятного побочного эффекта, на Drizzle перестали проходить многие популярные разновидности "sql-injections" для MySQL, так что безопасность стала невольным бонусом этого проекта, попутно демонстрируя нам всем глубокие философские выводы о том, что минимализм почти тождественен безопасности. SkySQL

Рассмотрев, так сказать, крайности – макси- и мини-варианты оригинального MySQL, давайте посмотрим, какие имеются более традиционно-классические продолжения этого известного проекта. На фоне тотального исхода из Oracle разработчиков MySQL (из Oracle добровольно "катапультировалось" уже более 70% оригинальной команды MySQL AB), они, разбредаясь по миру, пытаются как-то заново подстроиться уже под новую историческую эпоху для MySQL.

Так появилась компания SkySQL, основанная уволившимися из Oracle разработчиками MySQL, частично финансируемая несколькими бывшими инвесторами MySQL AB и возглавляемая Ульфом Санбергом (Ulf Sandberg), бывшим вице-президентом по предоставлению глобальных сервисов MySQL. Новая компания пока не намерена развивать свой форк MySQL, а займется предоставлением коммерческой технической поддержки, консалтинговых услуг, обучением и продажей готовых решений на базе MySQL. Кроме того, SkySQL организовала выпуск и поддержку альтернативной промышленной сборки MySQL – SkySQL Enterprise. Продукт распространяется по подписке и снабжен полноценной технической поддержкой (помощь в решении проблем, консультации по настройке, устранение последствий сбоев) и консалтинговым сервисом (планирование внедрения и проведение оптимизации), т.е. фактически полностью перезапустила бизнес своего прототипа, ныне доставшегося Oracle, – шведской компании MySQL AB. Так вот, здесь очень интересно, что входит в состав этой самой SkySQL Enterprise? А входит туда, кроме сопутствующих утилит, "прозрачная замена" MySQL – MariaDB Server. MariaDB Server

Давайте остановимся и зададимся вопросом – что же такое MariaDB Server? Для этого немного откатимся в краткий исторический обзор, чтобы понять, откуда и зачем взялся этот очередной новый форк MySQL. Майкл "Монти", создатель и бессменный лидер проекта СУБД MySQL, покинув в конце 2008 года компанию Sun Microsystems и прекратив непосредственно участвовать в разработке MySQL, задумал создать максимально совместимый с MySQL, но идейно новый сервер, базирующийся на принципиально новом движке хранилища данных. Новое хранилище данных, используемое в MariaDB, – это устойчивый к сбоям клон MyISAM. Многие специалисты отмечают, что Maria Engine это, как минимум, один из лучших движков для выборки данных из всех, что сейчас существуют, тогда как в классической MySQL дефолтный MyISAM – её самое слабое место.

В новой компании вместе с Монти над проектом работают около 20 сотрудников – бывших разработчиков из MySQL AB, ушедших из Sun вслед за своим идейным лидером. Создатель MySQL заявляет, что в MariaDB Server обеспечивается максимально точная и совместимая интерфейсная копия SQL, используемого в оригинальном MySQL 5, тогда как внутри этот сервер уже во многом превосходит свой прототип, давший ему жизнь и стартовую кодовую базу. Более того, Монти заявил, что MariaDB отныне является единственной официальной версией MySQL, тогда как Oracle MySQL "is now dead". Самое страшное в этом молодом проекте – это то, что многие недовольны женским названием новой СУБД: ну, так одну из дочерей автора MySQL зовут My, а вторую – Maria. Отсюда и названия систем. Есть, правда, ещё один сын, и зовут его, на всякий случай, Max. И MaxDB уже, кстати, создана, но здесь о ней не будет сказано ни слова.

Таким образом, суммируя, часть разработчиков после ухода из Sun и Oracle осела в компании Monty Program, где день и ночь они пилят новый-старый MySQL, но под уже новым названием – MariaDB Server, тогда как вторая часть программистов и сервисного персонала из бывшего MySQL AB основала компанию SkySQL по сопровождению и поддержке MariaDB Server. И кстати, по-моему мнению, MariaDB Server – это самая качественная и сбалансированная замена для MySQL после того, как Oracle эту СУБД похоронит (а по моему субъективному мнению, ждать этого осталось уже не долго, и первые звоночки как бы даже уже позванивают).

Например, на моем хостинге MariaDB прекрасно работает в связке с PHP5, обслуживая обычные WordPress'ы и прочие популярные движки, для работы с БД настроен обычный PhpMyAdmin, сами пользователи хостинга о существовании такой БД даже и не подозревают, принимая её за всамделишную MySQL. Хотя ради справедливости стоит заметить, что сами разработчики говорят, что расхождение с кодовой базой MySQL уже сейчас достигло примерно 20 процентов и будет, конечно, нарастать и дальше. Также мною проверялась работа MariaDB в связке с MySQL Proxy и специализированным файрволом для MySQL – GreenSQL: обе софтины работали с MariaDB прямо как с родной MySQL, так что думаю, что, как минимум, одна достойная и очень перспективная альтернатива MySQL уже состоялась. Хочется добавить, что MariaDB Server, как и Drizzle, очень активно развивается и эволюционирует. По крайней мере, каждый из этих двух проектов очень хорошо смотрится в своих, несколько разных целевых нишах. OurDelta

Следующий проект, который мы кратко рассмотрим, – это дистрибутивы OurDelta. На самом деле, это популярные ре-сборки двух upstream-проектов: для MySQL 5 поддерживаются два параллельных дистрибутива – OurDelta и OurDelta-Sail. Если в первый дистрибутив включаются билды, собранные с применением к стандартным сырцам MySQL 5 только хорошо протестированной коллекции сторонних "неканонических" патчей, то во вторую, отчасти экспериментальную ветвь включается всё самое прогрессивное и максимально свежее, что имеется на момент релиза, но понятно, что часто оно толком ещё не обкатано как следует в реальных условиях, со всеми вытекающими отсюда последствиями.

Кроме этого, в параллельной ветке OurDelta расширяется и функциональность MariaDB 5, которая считается прямым конкурентом и приемником MySQL, но здесь на данный момент есть только одна ветка сборок – стабильная для MariaDB. Что же это за такие патчи, которыми регулярно потчует нас проект OurDelta?

Основная часть рабочего материала – это адаптация в одну ветвь суммарных наработок MariaDB Server, а также патчсета компании Google, который она развивает для своих собственных нужд, масштабируя и расширяя (порой весьма радикально) функциональность оригинального MySQL. Следующий крупный донор проекта – это патчсеты от Марка Калагхана (Mark Callaghan) из Facebook, который ожесточенно "пилит под себя" MySQL для этой компании уже пятый год. Кроме того, используются патчи ряда других компаний, перечислять которые здесь нет смысла в силу их предельной малоизвестности широкому кругу читателей и писателей навроде меня. Таким образом, проект OurDelta – это своего рода "MySQL/MariaDB на стероидах", делающий продвинутые, накачанные новой функциональностью сборки MySQL/MariaDB на любой цвет и вкус. Хотелось бы лишь отметить, что в OurDelta очень охотно используют патчи также и от такого самобытного проекта-форка, как Percona, на котором давайте сейчас остановимся немного поподробнее. Percona

Компания Percona основана в 2008 году двумя отечественными разработчиками, уже бывшими членами MySQL dev.team Петром Зайцевым и Вадимом Ткаченко. Их сервер баз данных основывается на кодовой базе MySQL 5.1, которая дополнена собственными многочисленными и (что хочется отдельно подчеркнуть) весьма качественными патчами, направленными на добавление новой функциональности, повышение стабильности работы и повышение удобства администрирования. Но главная фича проекта – интеграция собственного движка XtraDB, основанного на коде InnoDB-plugin и полностью совместимого с ним, но отличающегося существенно более высокой производительностью. Кроме того, Percona поставляет вместе с этим движком очень мощную бэкаповую систему XtraBackup, которая позволяет решать и автоматизировать даже самые экзотические задачи из области сохранности данных, вверенных на хранение серверу БД.

Так вот, в экспертных кулуарах сейчас (на конец 2010 года) как бы считается, что основная острая конкуренция разгорается именно между движками Maria Engine (движок совсем недавно был переименован в Aria) и как раз Percona XtraDB – никаких более продвинутых на данный момент storage engines просто нет в природе, так что старичок MySQL будет потихоньку по-любому сдавать свои позиции на фоне его более активных и озабоченных развитием конкурентов, если, конечно, Oracle вдруг не опомнится и не станет вкладывать силы/ресурсы в дальнейшую глубокую разработку системы.

В дополнение, здесь можно посмотреть интересное видео с выступлением члена команды Percona Евгения Степченко, в котором дается подробный обзор проекта Percona. NoSQL

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

Ещё один бывший участник MySQL dev.team Йошинори Мацунобу (Yoshinori Matsunobu) в своей подробной технической статье (см. также ее перевод на русский язык) рассказывает об этой новой методике, а также делится тестами и реальным кодом клиентов, который можно уже прямо сейчас использовать в высоконагруженных проектах.

Ну что тут сказать – решение очень красивое. Плагин HandlerSocket позволяет гибко переключаться между обычным SQL-синтаксисом из обычных клиентов и собственным протоколом для перехода в NoSQL-режим сверхвысокой производительности. И всё это чудо мгновенного преобразования MySQL в суперпроизводительную СУБД доступно на самом обычном железе! Работая в этом режиме, Йошинори фактически уперся в пропускную способность имеющегося канала (1Gb), так что расти ещё есть куда ;-) Завершая свою обзорную статью о жизненном цикле MySQL, хочу пожелать вам вдумчивого выбора, приемлемых нагрузок на ваших серверах БД, а всем нам вместе – дальнейшего развития замечательных форков, широкое разнообразие которых объединяет только одно: общий знатный родитель – чудесная СУБД MySQL!