Содержание статьи
Что будет теперь, когда ненавистная и даже глубоко противная истинным сторонникам открытого софта компания Oracle купила многострадальную Sun, а заодно и наш с тобой любимый MySQL? Конец легендарного продукта? Может быть. Но уже сейчас есть куда более функциональные и полностью совместимые разработки!
MySQL, он же просто "мускул". Бьюсь об заклад, что это единственная СУБД, которая по умолчанию доступна на твоем хостинге. Любимые движки для форума и блога работают на ней. Это фактически стандарт де-факто для любого веб-продукта. Да и в своих проектах ты, вероятнее всего, используешь именно ее. В Сети миллионы сайтов осуществляют запросы и сохраняют данные в БД с помощью MySQL. И все было просто и понятно до тех пор, пока компанию Sun вместе с ее любимым мускулом неожиданно не купила корпорация Oracle. Учитывая, что основным продуктом последней является мощнейшая СУБД с одноименным названием, сообщество сильно тревожилось о дальнейшей судьбе MySQL. И не напрасно. Компания Oracle, конечно же, выступила с заявлением, что все в порядке: проект по-прежнему будет развиваться. Но многим верится в это с трудом. Ведь даже быстрый выпуск версии 5.5, которую многие так ждали, не дал положительных результатов: старые баги как были, так и остались. Разве ж это дело? Но параллельно с оригинальным MySQL уже давно развиваются альтернативные проекты, которые совместимы с оригинальной СУБД, но во многом даже превосходят ее. И об этом мы сейчас и поговорим.
Движок БД — что это такое?
Если немного упростить понятия, то база данных — это обертка вокруг движка хранения данных. Она занимается приемом запросов и управлением ими, кэшированием и прочими обслуживающими функциями, обеспечивая работу с низкоуровневым API движка. Последний, в свою очередь, собственно и хранит данные (на диске или в памяти), работает с операционной системой и обеспечивает выдачу нужных выборок по запросу от сервера. Если раньше СУБД (связка "сервер + движок") была монолитная, то теперь во всех системах используется структура с плагинами. Движок в такой организации является просто модулем, а сам сервер не зависит от системы хранения данных. В последних редакциях классического MySQL также используется плагинная архитектура. Поэтому встроенный движок InnoDB (правда, обычно устаревшей версии) можно легко заменить на модуль другого проекта, который часто будет лучше. В альтернативных мускулу разработках, в том числе MariaDB или Drizzle, все движки изначально выполнены как плагины. Попробую кратко пробежаться по современным движкам хранения данных в MySQL-совместимых СУБД.
- InnoDB — основной движок для мускула, который с версии 5.5 наконец-то сделали дефолтным. Поддерживает транзакции, репликацию, построчную блокировку. Достаточно устойчив к сбоям.
- MyISAM — очень проблемный движок, плохо переносящий крах сервера. Не поддерживает транзакции, но зато может похвастаться полнотекстовыми индексами и быстротой работы. Долгое время был стандартным для всех версий MySQL, а потому до сих пор является самым популярным.
- Aria — замена для MyISAM с поддержкой транзакций и улучшенной работой с памятью. Движок гарантирует целостность данных и при этом не уступает в скорости MyISAM.
- CVS — специализированный движок на случай, когда требуется хранить и обрабатывать большие массивы строковых данных, разделяемых запятой.
- Federated/FederatedX — этот движок специализируется на прозрачном разнесении данных по нескольким серверам (физическим) на уровне таблицы.
- PBXT — призванный заменить InnoDB новый движок, в котором реализованы полная поддержка транзакций, многоверсионность, автоматическая обработка дедлоков. Движок оптимизирован для большого количества одновременных транзакций.
- Blackhole — служебный движок, представляющий собой, по сути, /dev/null для СУБД и фактически не производящий никаких записей на диск. Используется для репликации.
- Archive — движок, который максимально быстро работает на запись. Используется в тех случаях, когда необходимо хостить большие массивы данных. Для эффективности хранения используется сжатие, что приводит к медлительности во время выборок. Движок хорошо подходит для долговременного хранения логов и другой служебной информации.
- XtraDB — расширенная и исправленная в некоторых проблемных местах InnoDB от компании Percona.
- MERGE — схожий с Federated движок для разнесения данных в одной таблице на несколько разных.
- MEMORY — движок, использующийся для хранения данных не на диске, а в памяти. Информация из базы доступна только во время работы сервера, но это дает колоссальный прирост в производительности.
- BlitzDB — еще одна замена для MyISAM с хорошей производительностью за счет встроенного построчного кэширования и автоматического восстановления после сбоев. Движок не поддерживает транзакции.
- NDB — движок для кластера, обладающий, впрочем, кучей проблем и удручающе плохой производительностью.
- Falcon — легендарный движок от компании MySQL AB, разрабатываемый еще со времен Sun, когда было принято решение заменить оракловский InnoDB.
- SphinxSE — полнотекстовый движок от создателя поискового сервера Sphinx. Лучший вариант для полнотекстового поиска и индексации по правилам русского языка. Легко оперирует терабайтами данных, обеспечивая при этом все возможности современной БД.
Важная вещь — совместимость
Итак, мы взялись за непростую задачу — найти замену для MySQL. Но если менять, то на что? Только не беги с криками "Да отстой ваш мускул — бери слона, то есть PostgreSQL". Не выйдет! Сейчас столько кода написано с поддержкой MySQL, что переписать или искать замену — себе дороже. Причем в прямом смысле — часто уложиться в рамки разумных финансовых затрат просто невозможно. Хорошо, если речь идет о простецком форуме или блоге (обычно в них реализована поддержка сразу нескольких систем). Но что если это что-то самописное или заточенное под возможности именно MySQL? Тут все ох как непросто. Так что наша задача — сохранить мускулы (то есть полную совместимость с MySQL), но прокачать их так, чтобы не зависеть от старшего тренера и его стероидов.
Разработчики и идеологи самого MySQL далеко не дураки и сами предвидели ситуацию, что после поглощения сложно будет всем. Некоторые из них решили даже покинуть компанию и основать свои проекты, прихватив тогда еще свободные коды мускула. Благодаря этому сейчас есть несколько интересных продуктов, основанных на коде оригинального сервера, но с большими доработками и изменениями во всем, куда только удалось дотянуться разработчикам. Первым делом энтузиасты освободились от бремени движка InnoDB, правами на который уже давно обладает все тот же самый Oracle. На замену ему выкатили несколько движков, которые стали доступными в MariaDB.
Архитектура MySQL — теперь уже как пособие по устройству некогда великой СУБД
MariaDB
История этого сервера уходит в далекий 2008 год, когда один из главных разработчиков MySQL, осознавая, что сильно связан поставленными работодателем рамками, уволился и основал свою компанию, которая занялась исправлением родовых травм MySQL. Я говорю о дефолтном движке MyISAM, который необходимо было менять, и критических багах, на исправление которых уходило неприемлемое количество времени. Что получилось у создателей MariaDB? Замечательный продукт, который на уровне протокола, формата файлов и языка SQL идентичен с оригинальной версией MySQL. Это предоставляет возможность безболезненного перехода: без потери данных или изменения логики работы имеющегося кода.
"Но какие бонусы я получу от перехода?", — спросишь ты. Взамен мы получаем большую скорость работы и новые фичи, которых, возможно, вообще никогда не будет в мускуле. Например, интегрированный в сам сервер поисковый движок Sphinx, который не придется ставить отдельно, расширенные возможности по бэкапу и управлению данными и так далее.
Надо сказать, что многие очень крупные компании (в том числе такие звери, как Google и Facebook) давно используют MariaDB. По сети гуляет специальный набор патчей, которые после наложения на исходные коды оригинального мускула решают многие проблемы. Однако не жди их появления в официальном сервере — если за столько лет не сподобились, то вряд ли в следующей версии решатся. Разработчики MariaDB же пока свободны от корпоративных правил и маркетинговых ограничений, поэтому новые патчи и исправления багов принимаются достаточно быстро.
Если оригинальный мускул держится на двух китах — движках хранения данных InnoDB и MyISAM, то MariaDB использует свои собственные, выступающие продвинутыми заменителями. Движок Aria пришел на замену MyISAM и на деле куда более производителен благодаря построчному кэшированию и оптимизированному формату упаковки данных. Если оригинальный MyISAM был быстр за счет отказа от транзакций, что означало возможную потерю данных, то Aria одновременно и производителен, и безопасен. За счет улучшенных форматов для хранения информации MariaDB существенно быстрее восстанавливается после сбоев, не требуя отдельных процедур проверки данных после краха. Принадлежащий Oracle движок InnoDB заменен на XtraDB, разработку другой компании в области БД Percona. Последняя известна своими сборками MySQL с интегрированными патчами от Гугла и Фейсбука, а также расширенными инструментами администрирования. Команда имеет необычную историю (подробнее ты можешь прочитать во врезке) и сейчас активно занимается созданием нового мускула. Для обратной совместимости с MySQL движок XtraDB в MariaDB даже называется точно так же, то есть InnoDB. Но надо понимать, что на самом деле сохранилось только название, дабы не смущать софт непривычными идентификаторами.
Первым проектом молодой компании Oracle была разработка по заказу разведчиков учетной системы, за которую на конкурсе другие компании запрашивали под $2 000 000, а молодой Ларри Элисон заносчиво указал сумму всего в $300 000. Стоит ли говорить, что проект был провален, зато компания получила стартовый капитал и начала свое восхождение.
Дополнительные движки
Об XtraDB стоит поговорить более детально: по мнению многих специалистов это номер один в мире движок для БД. Более того, он обставляет оракловский InnoDB, как маленького :). Ключевая фича — долгожданная поддержка многоядерных и многопроцессорных систем, чем ну никак не хочет (или не может?) похвастаться MySQL. Патчи от Google давно решили эту проблему, но, как всегда, их не удосужились включить в оригинальный движок, поэтому MySQL с точки зрения производительности плетется далеко позади по любым бенчмаркам. Разработчики XtraDB значительно улучшили стратегию использования дискового I/O, что раньше ограничивало производительность из-за тормозов со сбросом данных на диск из кэша. Соответствующими опциями теперь можно тонко управлять из настроек, что позволяет особо продвинутым админам подтюнить производительность демона самому, не обращаясь к дорогим специалистам по базам данных. Тем более, что из коробки доступна детальная статистика по работе движка, что сводит на нет потребность в дорогом коммерческом софте для анализа производительности базы данных. Нужна лишь одна команда SHOW ENGINE INNODB STATUS. И немаловажный момент — скорость восстановления после сбоя: если уж он и случился, восстановление будет не просто быстрым, а почти реактивным, зачастую до десяти раз быстрее, чем в MySQL. А также множество других мелочей: буферы для записей, адаптивные чекпоинты и увеличенное число открытых транзакций. Все это позволит серверу хорошо чувствовать себя в очень нагруженных условиях.
Если тебе и этого не хватает, и ты киваешь головой в сторону Firebird или PosgreSQL, намекая, что там есть и полная поддержка транзакционной модели и даже MVCC (Multiversion Concurrency Control — конкурентная модель данных на базе версионности, что позволяет без блокировок производить обновление и чтение одной и той же строки данных) — расслабься. В MariaDB доступен движок PBXT, который в некоторых ситуациях еще более крут, чем все вышеперечисленные. Правда, тут сразу стоит сказать, что он не такой универсальный и его нужно уметь готовить! PBXT в основном заточен под большое количество транзакций, которые пишут или изменяют данные, поддерживает быстрый откат и умеет сам разрешать сложные ситуации с блокировками и дедлоками. Например, если хочешь сделать хранилище логов, то у тебя будет огромное количество операций записи в таблицу, но сравнительно мало чтения. В то же время, если кто-то все-таки захочет сделать выборку из БД, он получит максимально свежие данные, не мешая при этом записи новых. И для совсем уж извращенцев есть движок FederatedX, умеющий распределять таблицу данных на несколько физических серверов, а также OQGRAPH, оптимизированный для хранения иерархических структур, графов и деревьев. Подход, идеально подходящий для создания клона Facebook и ВКонтакте, где требуется работать с социальным графом отношений между людьми, что плоховато вписывается в типичную модель баз данных.
Cloud Computing
Разработчики другого проекта — Drizzle — пошли по немного другому пути и решили вообще переосмыслить место базы данных в инфраструктуре типичного проекта. Вспомнили, что сейчас модно: cloud computing, Google Proto Buffers, масштабируемость, многоядерность и прочее. И подумали: база данных также должна двигаться вместе с современными технологиями, а не плестись в конце, вне зависимости от того, что на ней крутится — блоговый движок или крупная корпоративная CRM-система. Под шумок было решено упростить функционал оригинальной MySQL, выкинув тянущиеся из релиза в релиз возможности, которые в действительности мало кому нужны. Система утратила поддержку UNIX-сокетов (это хотя и спорное, но вполне допустимое решение ввиду направленности на облачные среды) и версию для Windows. В Drizzle нет никаких служебных баз и многих других привычных вещей. Но что же тогда есть?
Drizzle благодаря простой микроядерной и плагинной архитектуре умеет многое
А есть архитектура с микроядром, в которое вынесены все основные операции и поддержка протоколов, а также система плагинов, позволяющая расширить систему в любую сторону и на любую глубину. В качестве одной из основных системных компонент используется бинарный протокол от Google — Protocol Buffer. С его помощью описываются как таблицы, так и данные, он же применяется и для репликации. Основной упор в разработке сделан на максимальную поддержку многопоточности и многопроцессорности, так что масштабируемость — это основное достижение разработчиков. Реализована поддержка как стандартного MySQL-протокола, так и собственного варианта — через библиотеку libdrizzle и драйвера для большинства популярных языков, включая Perl, PHP, Python и Lua. При желании можно использовать клиентскую библиотеку и без самого сервера: в этом случае ты получишь эффективный асинхронный доступ к любимому MySQL. Поскольку эта же компания разработала и систему Gearman, то в Drizzle есть встроенная поддержка логирования в распределенной среде, нативное кэширование в memcache и даже такие продвинутые возможности, как репликация через системы сообщений типа RabbitMQ (используется в том числе новомодная технология WebSocket). В качестве основного движка хранения данных в Drizzle используется особая версия InnoDB, значительно переработанная и дополненная набором сторонних патчей. Также доступны движки XtraDB и PBXT. Если первые версии Drizzle основывались на MySQL 5.0, то теперь от оригинальной СУБД осталось немногое. Это почти полностью переписанный код с минимальной оглядкой на бывших родственников. На данный момент разработка Drizzle пребывает в активном состоянии, и к весне планируется первый стабильный релиз.
NoSQL-тренд
Ты наверняка знаешь о новомодном тренде NoSQL. По сути, это отказ от традиционного сервера базы данных с его таблицами и SQL-запросами и уход к самой простой схеме хранения данных "ключ-значение" (key-value). Для реализации последнего часто используются продвинутые типы данных вроде списков/хэшей (в Redis) или, например, формата JSON (в MongoDB). Но что мешает скрестить удава и ежа, используя, с одной стороны, всю мощь и годами отработанную технологию баз данных и их движков, а с другой — упрощенный протокол и отказ от громоздкой прослойки в виде обработки SQL-языка запросов? Суровым наследникам самураев не помешало ничего: японские парни из Yoshinori Matsunobu сделали плагин HandlerSocket, превращающий стандартный движок InnoDB в продвинутое NoSQL-хранилище, не мешая при этом работе обычного SQL. Скорость работы впечатляет: до 750 000 операций в секунду! Неудивительно, что компания Percona сразу же взяла на вооружение этот плагин, включив его в свои сборки сервера. Круто! Но, с другой стороны, как еще если не костылем можно назвать решение, которое имитирует то, что у нормальной БД типа Drizzle реализовано прямо из коробки в силу внутренней архитектуры?
Делаем выводы
Если ты обеспокоен развитием MySQL, тебе не нравится политика Oracle и ты справедливо опасаешься, что завтра тебя обяжут платить за функционал, который еще вчера был бесплатен, посмотри вокруг. Сообщество отреагировало на покупку MySQL как на начало заката технологии, некогда выведшей современный веб на недостижимую высоту благодаря стеку LAMP (Linux-Apache-MySQL-PHP). Ключевые разработчики начали развитие собственных форков, некоторые из которых уже сейчас на голову превосходят старый MySQL. За ними стоят многие знаковые фигуры и открытое сообщество. Сделав все по уму, разработчики умудрились оставить 100% внешней совместимости с приложениями и протоколами. Поэтому все желающие поставить новый сервер не окажутся у разбитого корыта: данные сохранятся, а приложения не придется переписывать. Многие вообще не заметят разницы, кроме возросшей скорости работы и надежности.
Уже сейчас ты можешь заменить свой сервер баз данных, так что имеющиеся приложения даже не почувствуют разницы, получив при этом гораздо большую скорость работы, надежность и массу недоступных в оригинальном мускуле фишек. MariaDB с набором движков — отличный вариант для старта. Ну а если ты задумал грандиозный проект с большим количеством серверов и гигабайтами данных, посмотри на Drizzle. Как программный продукт и как сервер баз данных он является очень перспективной разработкой, которая обязательно выстрелит уже в этом году. Если же хочется стабильности и поддержки самыми лучшими специалистами по базам данных — не бойся отвернуться от Oracle и пойти к Perconа. Ребята раздают бесплатно свою версию СУБД — исправляя, насколько это возможно, баги и добавляя фичи для увеличения производительности оригинального MySQL, не нарушая при этом совместимости. Ты все еще сидишь на стареньком мускуле? Тогда мы идем к тебе!
Links
