Alpha-Beta-Release Blog

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Oracle, купив Sun, подготовило закат солнца вручную, медленно убивая самую лучшую СУБД в мире – MySQL. Но что делать, если очень хочется быстрой и свободной базы, но без  призрака оракла за спиной?

Твой любимый форум работает на MySQL (на мускуле, если кратко), а на работе или в вузе крутиться система учета чего-либо, написанная твоими друзьями под пиво и за получение зачета? И тоже на мускуле? Да в вебе тысячи и миллионы сайтов используют MySQL как базу данных. Но что будет теперь, когда ненавистный и глубоко противный истинным опен-сорсникам Oracle купил многострадальную Sun, а заодно и наш с тобою любимый мускул? От неудачников, кинувших даже ЦРУ, не стоит ждать качественного развития свободных проектов. Да-да, я отвечаю за базар – первым проектом молодой компании Oracle была разработка по заказу разведчиков какой-то учётной системы, за которую на конкурсе другие компании просили под 2 млн, а молодой Ларри Элисон заносчиво запросил за все жалкие 300 тысяч. Стоит ли говорить, что проект был провален, зато компания получила стартовый капитал и начала свое восхождение. Хотя уже поздно бить тревогу, все пацаны давно в курсе, что лучший (читай – наименее ущербный) движок для хранения данных в мускуле – это InnoDB, права на который у Oracle были давным давно. Так что, если ты сейчас чешешь репу, что бы выбрать взамен MySQL, ты удачно открыл журнал, я расскажу, чем можно заменить поделие империи зла. Но не беги с криками «да ваш мускул г…, бери слона (PostgreSQL) и будет все зашибись» - сейчас столько кода написано с поддержкой мускула, и зачастую в виде единственной базы данных, что переписать или искать замену себе дороже, а часто просто невозможно. Хорошо, если это форум или блог, обычно там сразу поддержка нескольких систем, а если что-то самописное и заточенное под возможности именно MySQL? Так что задача у нас с тобой самая что ни на есть простая – сохранить мускулы, но прокачав их так, чтобы не зависеть от старшего тренера и его стероидов. Oracle, конечно же, выступила с заявлением,  что все в порядке и будут развивать все по старому, но никто как всегда не поверил. Даже быстрый выпуск версии 5.5, которую многие ожидали, не дал положительных результатов – старые баги как были, так и остались, но по маркетинговым заявлением все ОК.

Разработчики и идеологи самого мускула далеко не дураки и сами предвидели ситуацию, что после поглощения всем будет не очень сладко, поэтому некоторые решили покинуть от греха подальше компанию и основать свои проекты, прихватил тогда еще свободные коды MySQL. Таким образом, сейчас есть несколько проектов, которые взяли за основу оригинальный сервер, но постепенно дописывали или переписывали все, до чего могли дотянуться. И первым делом – освободились от бремени InnoDB, правами на который обладает тот самый Oracle. На замену ему выкатили несколько движков, основной из которых – MariaDB.

Заморская красавица Мария

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

Главное – это то, что разработчики обещают (и пока сдерживают слово), что на уровне протокола, формата файлов и языка SQL все версии будут идентичные с оригинальной версией MySQL, поэтому переход будет безболезненный, без потери данных или изменения логики работы. Взамен ты получаешь большую скорость работы, новые фичи, который никогда не будет в мускуле (например, интегрированный в сам сервер поисковый движок Sphinx, который отныне не придется ставить отдельно), расширенные возможности по бекапу и управлению данными.

Кстати, многие очень крупные компании давно используют MySQL, в том числе такие звери как Google и Facebook. По сети гуляет специальный набор патчей, которые после наложения на исходные коды оригинального мускула решает многие проблемы. Однако не жди их появления в официальном сервере – если за столько лет не сподобились, вряд ли в следующей версии решаться. Разработчики MariaDB свободны пока что от корпоративных правил и маркетинговых ограничений, поэтому новые патчи и исправления багов принимаются достаточно быстро.

Если оригинальный Мускул держится на двух китах – движках хранения данных InnoDB и MyISAM, то наша Мария использует свои, выступающие продвинутыми заменителями. Aria в качестве замены MyISAM очень быстрая благодаря построчному кешированию и оптимизированному формату упаковки данных. Если оригинальный MyISAM был быстр за счет отказа от транзакций, что означало потерю иногда и всех данных, Aria же более быстрая, при этом умея поддерживать транзакции, а за счет улучшенного формата хранения, быстрее восстанавливается после сбоев, не требуя отдельных процедур проверки данных после краха.

Оракловый InnoDB теперь заменен на XtraDB, разработку другой компании в области БД, Percona, которая известна своими сборками мускула с интегрированными патчами от гугла и фейсбука, а также расширенными инструментами администрирования. Теперь они помогают сделать новый мускул.

Для обратной совместимости в марие этот движок даже называется точно так же, InnoDB, хотя на самом деле это только название, дабы не смущать софт непривычными идентификаторами.

О XtraDB стоит поговорить детальнее, так как это сейчас номер 1 в мире движков для БД, который вставляет оракловский InnoDB как маленького. Ключавая фича его – наконец то (!!) поддержка многоядерных и многопроцессорных систем, чем никак не мог похвастаться мускул. Патчи от Google давно решили эту проблему, но как всегда, их не удосужились включить в оригинальный движок, поэтому теперь плетутся далеко позади. Значительно улучшили и стратегию использования дискового I/O, что раньше ограничивало производительность из-за тормозов со сбросом данных на диск из кеша. Более того, теперь этими опциями можно тонко управлять из настроек, что позволяет особо продвинутым админам подтюнить бд самому, без дорогих DB-шников. Для тех же админов будет радостно увидеть детальную статистику по работе движка, что сводит на нет нужность дорогого коммерческого софта по анализу производительности –  хватает команды SHOW ENGINE INNODB STATUS. И наконец, скорость восстановления после сбоя, если он уж случился, теперь не просто выше, а почти реактивная, часто в 10 раз быстрее, а значит отмазаться, почему ничего не работает третий день после внезапного отключения электричества уже не получиться, все будет работать в тот же день. Ну и из мелочей – буферы для записей, адаптивные чекпоинты и увеличенное число открытых транзакций позволит серверу хорошо чувствовать себя в очень нагруженных условиях.

Если тебе и этого не хватает, ты умный и киваешь головой в сторону Firebird или PosgreSQL, намекая, что там есть и полная поддержка транзакционной модели и даже MVCC (Multi-version Concurrency Control – конкурентная модель данных на базе версионности, что позволяет без блокировок производить обновление и чтение одной и той же строки данных) – расслабься, в MariaDB есть PBXT, движок в некоторых ситуациях еще более крутой, чем все предыдущие (хотя он не такой универсальный и его нужно уметь готовить). В основном, этот движок заточен под большое количество транзакций, которые пишут или изменяют данные, поддерживает быстрый откат  и умеет сам разрешать всякие ситуации с блокировками и дедлоками. Например, если хочешь сделать хранилище логов, то у тебя будет дофигища операций записи в таблицу, но сравнительно мало чтения, но если кто читает – он будет получать максимально свежие данные, не мешая при этом записи новых.

И уже для совсем уж извращенцев есть FederatedX, умеющий распределять таблицу данных на несколько физических серверов, а также OQGRAPH – движок оптимизированный для хранения иерархических структур, графов и деревьев, например, идеально подходящий для создания клона facebook-а и вКонтакте, где требуется работать с социальным графом отношений между людьми, что плоховато вписывается в типичную модель баз данных.

Короче, ты все прекрасно понял – собрались пацаны, бывшие сотрудники и разработчики из оригинального MySQL, посмотрели по сторонам, понимая, что под крышей то одной, то другой корпорации им не выжить и не развить открытый проект, и сделали убийцу своего же продукта, но так, как считали нужным, исправив то, что не получалось в родной компании. Заодно не сторонились и помощи других компаний, интегрировав наработки умных людей. Сделав все по уму, они оставили 100% внешней совместимости с приложениями и протоколами, так что желающие поставить новый сервер не окажутся у разбитого корыта – все данные сохраняться, приложения переписывать не надо, они вообще ничего не заметят, кроме возросшей скорости работы и надежности. Вот так то. А ты все еще на стареньком мускуле сидишь? Тогда мы идем к к тебе…

Мы наш, мы новый мир построим

Разработчики другого проекта, Drizzle, решили переосмыслить само место базы данных в инфраструктуре типичного проекта. И поняли, что сейчас модно – cloud computing, Google Proto Buffers, масштабируемость, многоядерность и прочие модные словечки. А значит и база данных должна двигаться вместе с технологиями, а не плестись в хвосте, вне зависимости от того, что на ней крутиться – WordPress блоговый движок или крупная корпоративная CRM-система.

Под шумок решено было упростить функционал системы, выкинув тянущиеся из релиза в релиз возможности, на самом деле никому не нужные. Поэтому система утратила поддержку UNIX-сокетов (хоть и спорное решение, но допустимо, ввиду направленности на облачные среды), убрана вообще поддержка Win-платформы, даже системное время не поддерживается произвольное, все операции внутри только с UTC. Также нет никаких служебных баз и прочего. А что есть?

А есть архитектура с микроядром, когда все основные операции и поддержка протоколов вынесена в легкое ядро, а также система плагинов, позволяющая расширить систему в любую сторону и на любую глубину. В качестве одной из основных системных компонент, используется поддержка бинарного протокола от Google – Protocol Buffer, в котором описываются и таблицы и данные, он же применяется и для репликации. Основа всего сервера – максимальная поддержка многопоточности и многопроцессорности, так что масштабируемость – это основное достижение разработчиков. При этом достигается как поддержка стандартного MySQL протокола, так и собственного варианта, через библиотеку libdrizzle и драйвера для большинства популярных языков, включая Perl, PHP, Python и Lua. Если хочешь, можно использовать клиентскую библиотеку и без самого сервера, тогда получишь эффективный асинхронный доступ к любимому MySQL.

Поскольку автор Drizzle разработал и уже ранее описываемую систему Gearman (см. Хакер номер о распределенных системах на РНР), то есть встроенная поддержка логирования в распределенной среде, нативная поддержка кеширования в memcache и даже такие продвинутые возможности как репликация через системы сообщений типа RabbitMQ и даже используя новомодный WebSocket.

Как основной движок хранения данных используется InnoDB, значительно переработанный и с учетом сторонних патчей, а также XtraDB и PBXT. Если первые версии Drizzle основывались на следующей версии MySQL 6.0, то теперь это почти полностью переписанный код, с минимальной оглядкой на бывших родственников.

На данный момент разработка Drizzle пребывает в активном состоянии, планируется первый стабильный релиз на весну этого года, тогда можно будет говорить о восходе нового конкурента  для MySQL.

Короче, и чё?

Если ты обеспокоен развитием MySQL, тебе не нравиться политика Oracle (а кому она нравиться) и ты справедливо опасаешся, что завтра тебя обяжут платить за ещё вчера базовый функционал открытой системы и заберут исходники – смотри вокруг. Сообщество отреагировало на покупку MySQL как на начало заката технологии, некогда вывевшей современный веб на недостижимую высоту благодаря стеку LAMP (Linux-Apache-MySQL-PHP), ключевые разработчики начали развитие собственных форков, некоторые из них уже сейчас на голову превосходят старый MySQL, при этом за ними стоят не менее знаковые фигуры и открытое сообщество. Так что ты смело сможешь заменить свой сервер базы данных так, что приложение даже не почувствует разницы, одновременно получив гораздо большую скорость, надежность а также и просто недостижимые в обычном сервере фичи. Ну а если задумал грандиозный проект, у тебя куча серверов и гигабатйты данных – посмотри на Drizzle, и как программный продукт и как сервер баз данных он очень перспективная разработка, которая выстрелит в этом году.

Если же хочется стабильности и крутой поддержки самыми лучшими специалистами по базах данных – смело плюй Ораклу в лицо и иди к Perconа – они раздают бесплатно свою версию СУБД, исправляют баги и добавляют фичи для убыстрения стандартного мускула настолько, как только можно, не нарушая совместимости ни на капельку. Ну а за деньги они не только научат, как его готовить, но и допишут все, что захочешь.

Движок, что в тебе такое?

Собственно, база данных – это обертка вокруг движка хранения данных. Она занимается приемом и управлением запросами, кешированием и прочими утилитными функциями, обеспечивая работу с низкоуровневым API движка. Он же в свою очередь собственно сам и хранит данные (на диске или в памяти), работает с операционной системой и обеспечивает выдачу нужных данных по запросу от сервера. Если раньше СУБД = Сервер+Движок, то есть система была монолитная, то теперь во всех системах используется плагинная структура, когда движок это просто модуль, а сам сервер независим от системы хранения данных. В последних редакциях классического MySQL сервера также используется плагинная архитектура для InnoDB, хотя по правде – встроенный InnoDB, обычно устаревшей версии, можно заменить на плагин, который часто лучше. В новых вариантах, будь то MariaDB или Drizzle все движки изначально выполнены как плагины. Поскольку создание хорошего движка это сложная и трудоемкая работа, их создано относительно немного, каждый выделяется чем-то особенным, но требования к надежности очень и очень высоки, ведь в БД самое ценное это данные, а движок как раз сердце и мускулы, которые работают с ценнейшей информацией.

Современные движки хранения данных в MySQL-совместимых СУБД

• InnoDB – основной движок для мускула, начиная с версии 5.5 он наконец-то дефолтный. Поддерживает транзакции, репликацию, построчную блокировку  и достаточно устойчив к сбоям.
• MyISAM – очень долгое время основной и самый проблемный движок, плохо переносящий крах сервера, без транзакций, зато с полнотекстовыми индексами и очень быстрый. Дефолтный для MySQL всех версий, поэтому самый популярный.
• Aria – замена для MyISAM, с поддержкой транзакций, улучшенной работой с памятью и гарантирующий целостность данных, однако не уступающий в скорости MyISAM.
• CVS – специализированный движок, когда требуется хранить и обрабатывать большие массивы строковых данных, разделяемых запятой.
• Federated/FederatedX – специализируется на разнесении данных по нескольких сервера (физических) прозрачно, на уровне таблицы. Тот, который с приставкой Х – улучшенная и свободная реализация от сообщества, в противовес теперь уже Оракловской.
• PBXT – новый движок, призванный заменить InnoDB, с полной поддержкой транзакций, мультиверсионности, автоматически обрабатывающий дедлоки и оптимизированный для большого количества одновременных транзакций.
• Blackhole – служебный движок, по сути /dev/null для СУБД, не производящий никаких записей на диск, но используется для репликации.
• Archive – очень быстрый движок на запись, когда надо хранить большие массивы данных, использует сжатие, но достаточно медленный для выборок. Хорошо подходит для долговременного хранения логов и другой служебной информации.
• XtraDB – расширенная и исправленная в некоторых проблемных местах InnoDB от компании Percona. По сути, то, чем должен быть оригинальный InnoDB.
• MERGE – схожий с Federated движок для разнесения данных в одной  таблице на несколько разных.
• MEMORY – все данных хранятся в памяти и доступны пока работает сервер, зато самый быстрый вариант.
• BlitzDB – еще одна замена для MyISAM, без транзакций, очень быстрый, использует встроенное построчное кеширование и автовосстановление после сбоев.
• NDB – версия для кластера, однако обладает кучей проблем и удручающе плохой производительностью.
• Falcon – легендарный движок от самой MySQL AB еще со времен Sun-а, когда было принято решение заменить InnoDB, который был во владении Оракла.
• SphinxSE – полнотекстовый движок от создателя поискового сервера Sphinx. Лучший для полнотекстового поиска и индексации по правилам русского языка и легко оперирует террабайтами данных, обеспечивая еще и все возможности обычной БД.

Кто такие Percona?

Жила была такая контора – Percona, которая занимается консалтингом в области производительности базы данных. Но быстро поняв, что много не наконсалтишь, да и проблемы текущей ветки MySQL они понимали как никто другой, начали потихоньку спонсорить разработчиков, которые делали свои замены мускулу. Потом начали выпускать (да и сейчас продолжают) свою версию сервера, включая туда некоторые сторонние патчи и продвигая своим клиентам уже исправленную версию. При этом они не идут на поводу у корпораций и все еще предлагают версию 5.1, которая используя патчи обгоняет по скорости даже новомодную 5.5, разрекламированную Oracle. Движок PBXT как раз спонсировался и вырос именно в закромах Percona, казалось бы, скромных консультантов.

А как де NoSQL?

Наверное ты знаешь о новомодном тренде о NoSQL – по сути, отказ от традиционного сервера базы данных с его таблицами и SQL запросами и уход в обычный key-value хранение, часто сдобренное более продвинутыми типами данных вроде списков или хешей (в Redis) или напрямую хранение и запрос документов произвольной структуры сразу в JSON (в MongoDB). А что мешает скрестить удава и ежа, используя, с одной стороны, всю мощь и годами отработанную технологию баз данных и их движков, а с другой – упрощенный протокол и отказ от громоздкой прослойки в виде обработки SQL-языка запросов? Для суровых наследников самураев ничего - Yoshinori Matsunobu сделал плагин HandlerSocket, превращающий стандартный движок InnoDB в самое продвинутое NoSQL хранилище, не мешая между этим и работе простого SQL-а! Скорость работы впечатляет – до 750 тысяч операций в секунду! Percona сразу же взяла на вооружение этот плагин, включив его в свои сборки сервера, таким образом старичок MySQL еще поживет в мире NoSQL. Хотя признаемся, что это просто костыль, чтобы имитировать то, что в нормальной БД типа Drizzle реализовано просто из коробки в силу внутренней архитектуры.

Установка Percona MySQL и PBXT

Получить доступ к Percona серверу в Debian легче простого, просто добавь репозитарии:
deb http://repo.percona.com/apt lenny main
deb-src http://repo.percona.com/apt lenny main

Поставить поддержку движка PBXT чуть посложнее:

1. Выясняем, где директория плагинов (подразумеваем, что MySQL 5.1 у тебя уже установлен).
2. Для этого набери в консоли mysql клиента: show variables like "%plugin%" или выполни как SQL запрос через phpMyAdmin. Получишь что-то типа: /home/my-user/mysql/lib/mysql/plugin
3. Скачай исходники плагина из lanchpad-а, используя Bazzar:  bzr branch lp:pbxt /tmp/pbxt-src
4. Конфигурируем:  ./configure --with-mysql=<build-dir>/<mysql-src> --with-plugindir=<mysql-dir>/lib/mysql/plugin
5. Собираем: make && make install
6. Копируем полученный модуль в директорию плагинов и выполняем SQL команду: INSTALL PLUGIN pbxt SONAME 'libpbxt.so'
7. PROFIT!!! Создаем первую таблицу используя новый движок: CREATE TABLE t1 (c1 int, c2 text) engine=pbxt;  или изменяем уже существующую: ALTER TABLE t1 engine=pbxt;

Ссылки

SkySQL - http://www.skysql.com

MariaDB - http://mariadb.org

Percona - http://www.percona.com

Drizzle - http://drizzle.org

MySQL - http://mysql.com

HandlerSocket - http://bit.ly/a9B7Gh