Сервер реляционной базы данных 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.
Из множества приведу только один пример, зато самый яркий, - это увольнение самого автора и создателя MySQL Майкла Вайдиниуса (Michael "Monty" Widenius) из Sun, именно из-за причины чрезвычайно некачественного производственного цикла разработки 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 по архитектуре Брайаном Эйкером, и представляет собой упрощенный и более быстрый вариант 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, это же касается и всех других продвинутых фичей".
Да, действительно, для запуска очень многих, например, блоговых движков написанных в связке с MySQL уже под Drizzle - понадобится модификация и некоторый тюнинг кода этих движков, впрочем, как успокаивают разработчики, изменения эти невелики и возможностей Drizzle на самом деле более чем достаточно для полноценного функционирования большинства популярных CMS, тем более что сообщество уже кастомизировало многие известные php-движки под Drizzle, что позволяет показывать их рекордную производительность на том же железе, на котором раньше крутился старый-добрый MySQL. В качестве приятного побочного эффекта, на Drizzle перестали проходить многие популярные разновидности sql-injections для MySQL, так что безопасность стала невольным бонусом этого проекта, попутно демонстрируя нам всем глубокие философские выводы о том, что минимализм есть почти тождество слова безопасность.
SkySQL
Рассмотрев, так сказать крайности, макси- и мини-варианты оригинального MySQL, давайте посмотрим какие есть т.с. более традиционно-классические, продолжения этого известного проекта. На фоне тотального исхода из Oracle разработчиков MySQL (из Oracle добровольно "катапультировалось" уже более 70% оригинальной команды MySQL AB), они, разбредаясь по миру, пытаются как-то заново пристроиться уже под новую историческую эпоху для MySQL.
Так появилась компания SkySQL, основанная уволившимися из Oracle разработчиками MySQL, частично финансируемая несколькими бывшими инвесторами MySQL AB и возглавляемая Ульфом Санбергом, бывшим вице-президентом по предоставлению глобальных сервисов 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, но идейно новый сервер, базирующийся на принципиально новом движке хранилища данных. Используемое новое хранилище данных Maria - это устойчивый к сбоям клон 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. Отсюда и названия баз данных. Есть правда ещё один сын, и зовут его, на всякий случай, Макс. И 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. Следующий крупный донор проекта - это патчсеты от Марка Калагхана из 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 можно посмотреть здесь с Евгением Степченко.
NoSQL
В заключении хотелось бы сказать, что подбор наиболее подходящей к конкретному техническому заданию модификации MySQL вовсе не ограничивается выбором оптимального дистрибутива и тюнинга его настроек, но также и принципиальным режимом работы самого сервера. В качестве примера приведу недавнюю успешную реализацию подхода NoSQL на базе MySQL-сервера. Yoshinori Matsunobu, автор этого метода и нового плагина HandlerSocket, ещё один бывший участник MySQL dev.team, в своей подробной технической статье "Использование MySQL в режиме NoSQL - История о том, как достичь обработки 750,000 запросов в секунду" рассказывает об этой новой методике, а также делится тестами и реальным кодом клиентов, который можно уже прямо сейчас использовать в своих высоконагруженных проектах.
Ну что тут сказать - решение очень красивое, - при этом позволяет гибко переключаться между обычным SQL-синтаксисом из обычных клиентов, так и собственным HandlerSocket-протоколом для переключения в режим сверхвысокой производительности через реализованный в виде плагина NoSQL-режим работы MySQL, и всё это чудо мгновенного преобразования в суперпроизводительную БД - на самом обычном железе! Работая в этом режиме, автор фактически уперся в пропускную способность имеющегося 1Gb канала, так что расти ещё есть куда ;-)
Завершая свою обзорную статью о жизненном цикле MySQL, хочется пожелать вам вдумчивого выбора, приемлемых нагрузок на ваших серверах БД, и конечно же всем нам - дальнейшего развития замечательных форков, такое разное множество которых объединяет только одно - общий знатный родитель - замечательная СУБД MySQL!