MySQL: жизнь продолжается

Приобретение корпорацией Oracle компании Sun поставило под вопрос существование и характер дальнейшего развития сразу множества известных свободных технологий. В этой статье мне бы хотелось рассмотреть вкратце историю, современное состояние и динамику развития и перспективы такого известного и сверхзначимого для современного Интернета проекта, как сервер баз данных 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. Из множества приведу только один пример, зато самый яркий – это увольнение самого автора и создателя 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 года.

В развитии разных веток их разработчики пошли разными концептуальными путями. С одной стороны, сделана попытка наращивания еще большей функциональности и добавление множества новых фичей, - например, это проект компании 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”, для особенно требовательных пользователей СУБД этого класса.

Совершенно противоположной дорогой пошел другой популярный форк 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 на самом деле более чем достаточно для их полноценного функционирования, тем более что сообщество уже кастомизировало многие известные php-движки под Drizzle, что позволяет показывать их рекордную производительность на том же железе, на котором раньше крутился старый добрый MySQL. В качестве приятного побочного эффекта на Drizzle перестали проходить многие популярные разновидности sql-injections для MySQL, так что безопасность стала невольным бонусом этого проекта, попутно демонстрируя нам всем глубокие философские выводы о том, что минимализм есть почти тождество слова безопасность.

Рассмотрев, так сказать крайности, макси- и мини-варианты оригинального 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? Для этого немного откатимся в краткий исторический обзор, чтобы понять, откуда и зачем взялся этот очередной новый форк 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 уже состоялась.

Следующий проект, который мы кратко рассмотрим, – это дистрибутивы от проекта 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 основана в 2008 году двумя отечественными разработчиками, уже бывшими членами MySQL dev.team, Петром Зайцевым и Вадимом Ткаченко. Их БД-сервер основывается на кодовой базе MySQL 5.1, которая дополнена собственными многочисленными патчами, направленными на добавление новой функциональности, повышение стабильности работы и удобство администрирования. Но главная фича проекта - интеграция собственного движка XtraDB, основанного на коде InnoDB-plugin и полностью совместимого с ним, но отличающегося существенно более высокой производительностью. Кроме того, Percona поставляет вместе с этим движком очень мощную бэкаповую систему XtraBackup, которая позволяет решать и автоматизировать даже самые экзотические задачи из области сохранности вверенных на хранение серверу БД данных. Так вот, в экспертных кулуарах сейчас (на конец 2010 года) как бы считается, что основная острая конкуренция разгорается именно между движками Maria Engine и как раз XtraDB – никаких более продвинутых на данный момент storage engines просто нет в природе, так что старичок MySQL будет потихоньку по-любому сдавать свои позиции, если, конечно, Oracle вдруг не опомнится и не станет вкладывать силы/ресурсы в его дальнейшую глубокую разработку.

В заключение хотелось бы сказать, что подбор наиболее подходящей к конкретному техническому заданию модификации MySQL вовсе не ограничивается выбором оптимального дистрибутива и тюнинга его настроек, но также и принципиальным режимом работы самого сервера. В качестве примера приведу недавнюю успешную реализацию подхода NoSQL на базе MySQL-сервера. Yoshinori Matsunobu, автор этого метода и нового плагина HandlerSocket, еще один бывший участник MySQL dev.tem, в своей подробной технической статье (http://l-o-n-g.livejournal.com/153756.html) “Использование MySQL в режиме NoSQL - История о том, как достичь обработки 750.000 запросов в секунду” рассказывает об этой новой методике, а также делится тестами и реальным кодом клиентов, который можно уже прямо сейчас использовать в своих высоконагруженных проектах. Решение - очень красивое, при этом позволяет гибко переключаться как между обычным SQL-синтаксисом из обычных клиентов, так и собственным HandlerSocket-протоколом для переключения в режим сверхвысокой производительности через реализованный в виде плагина NoSQL-режим работы MySQL, и все это чудо мгновенного преобразования в суперпроизводительную БД – на самом обычном железе!

Завершая свою обзорную статью о жизненном цикле MySQL, хочется пожелать вам вдумчивого выбора, приемлемых нагрузок на ваших серверах БД, и, конечно же, всем нам – дальнейшего развития замечательных форков, такое разное множество которых объединяет только одно – общий знатный родитель, замечательная СУБД MySQL!

http://mysql.com/
http://www.extsql.com/
http://drizzle.org/
http://skysql.com/
http://mariadb.org/
http://kb.askmonty.org/v/mariadb
http://phpmyadmin.org/
http://forge.mysql.com/wiki/MySQL_Proxy
http://www.greensql.net/
http://ourdelta.org/
http://www.percona.com/
http://askmonty.org/wiki/Maria
http://www.percona.com/software/percona-xtradb/

Игорь САВЧУК


Компьютерная газета. Статья была опубликована в номере 43 за 2010 год в рубрике soft

©1997-2024 Компьютерная газета