Выбрать субд между mysql, postgresql, mariadb и mssql? Сравнение MySQL vs MariaDB MariaDB: что в ней есть нового.

Вы все еще используете MySQL?
А очень многие уже давно перешли на базу данных MariaDB.
Смотрите какой красивый логотип MariaDB с тюленем.

У MySQL тоже довольно красивый дельфин

Немного истории MariaDB из Википедии .
MariaDB - ответвление СУБД MySQL, разрабатываемое сообществом. Толчком к созданию стала необходимость обеспечения свободного статуса СУБД (под лицензией GPL), в противовес неопределенной политике лицензирования MySQL компанией Oracle.

Ведущий разработчик MariaDB - Майкл Видениус, он же автор оригинальной версии MySQL и основатель компании Monty Program AB.

Основная цель проекта MariaDB — создание полностью бинарно совместимой с оригинальной MySQL версии СУБД, которая при этом будет иметь значительное количество улучшений в коде, влияющих на производительность.

MariaDB разрабатывается как drop-in замена для MySQL, полностью имитируя поведение MySQL (и это действительно так).

MariaDB сейчас перспективный тренд, посмотрите на таблицу сравнения MySQL и MariaDB (особенно ветка 10.х)

Сравнение я взял с официального сайта MariaDB, там вы можете посмотреть подробнее на пункты. Хотя и без этого видно, что MariaDB 10.х явно лидирует.

Сейчас уже многие дистрибутивы Linux устанавливают MariaDB по-умолчанию вместо MySQL и секрет тут прост — МарияДБ поддерживает те же форматы хранения данных, таблицы и даже команды запуска и прочее, т.е. миграция на MariaDB получается легкой и незаметной. В FreeBSD тоже легко и просто провести установку MariaDB.

Например, тип таблиц Aria, оптимизирован для операций вставки в базу (они проходят заметно быстрее чем на MyISAM). Также таблицы Aria используются в MariaDB для внутренних процессов, все temporary tables работают именно на Aria, за счет этого повышается производительность на сложных запросах.

Фразы: сравнение MariaDB и MySQL, что лучше из баз данных?, скорость работы, установка MariaDB

Послужила необходимость обеспечения свободного статуса СУБД (под лицензией GPL), в противовес неопределенной политике лицензирования MySQL компанией Oracle . Продукт распространяется и используется согласно лицензии GNU GPL v.2, GNU LGPL.

Система написана с использованием: C, C++, Perl, Bash. Продукт работает под управлением ОС Linux и UNIX -подобных, Windows .

2014: MariaDB Enterprise 1.0

Развитие MariaDB курирует независимая организация MariaDB Foundation в соответствии с полностью открытым и прозрачным процессом разработки, не зависящим от отдельных вендоров. MariaDB поставляется вместо MySQL во многих дистрибутивах Linux (RHEL 7 , SUSE 12 , Fedora , openSUSE , Slackware, OpenMandriva, ROSA , Arch Linux, Debian 9). Система внедрена в проектах: Wikipedia , Google Cloud SQL и Nimbuzz.

Основные улучшения MariaDB 10.1

Поддержка шифрования таблиц и логов транзакций, которое позволяет защититься от утечки данных в случае кражи жесткого диска , но бесполезно в ситуации получения контроля над работающей СУБД , например, в результате атаки через подстановку SQL-запроса или взлома системы. При включении шифрования накладные расходы увеличиваются на 3-5%. Ключи шифрования имеет смысл хранить на отдельном защищённом сервере с включением системы ротации ключей, подразумевающей периодическое перешифрование с новым ключом после устаревания текущего ключа. Поддержка шифрования реализована в хранилищах XtraDB и InnoDB. Предлагается несколько схем: шифрование выбранных таблиц, шифрование всех таблиц в БД и шифрование всех таблиц за исключением выбранных. Благодаря шифрованию лога транзакций защита также обеспечивается в системах с репликацией;
Включение в базовую поставку технологии синхронной multi-master (active-active) репликации Galera, ранее предлагаемой в рамках отдельного продукта MariaDB Galera Cluster. Galera расширяет возможности СУБД MariaDB средствами синхронной репликации, при которой все узлы всегда содержат актуальные данные, т.е. гарантируется отсутствие потерянных транзакций, так как транзакция фиксируется только после распространения данных по всем узлам. При этом, в рамках транзакции операции выполняются сразу, задержка из-за ожидания подтверждения возникает только при выполнении операции "commit". Репликация выполняется в параллельном режиме, на уровне строк, с передачей только информации об изменениях. Управление принадлежностью узлов кластеру выполняется автоматически, сбойные узлы сразу исключаются из кластера без участия администратора, новые узлы при необходимости можно подключить на лету без дополнительной переконфигурации;
Возможность репликации данных c MySQL 5.6 при включении на MySQL поддержки GTID, т.е. MySQL теперь может использоваться в роли master-сервера для MariaDB. Указанная возможность позволяет существенно упростить тестирование в процессе миграции с MySQL на MariaDB;
Поддержка сжатия страниц данных для хранилищ InnoDB и XtraDB. От ранее доступного механизма сжатия (row_format=compressed) новый метод отличается возможностью выбора различных алгоритмов сжатия (zlib, lz4, lz0, lzma, bzip2 и snappy) и иной организацией процесса работы с упакованными данными. Если в традиционной реализации в буфере находятся как сжатые, так и ещё не упакованные данные, то новая схема подразумевает нахождение в буфере только распакованных данных - страницы сжимаются перед записью в хранилище и распаковываются после чтения. Новый метод наиболее эффективен при использовании SSD -накопителей или NVM-памяти. Наилучшие результаты наблюдаются при использовании плат FusionIO;
Реализована система дефрагментации хранилищ InnoDB, основанная на наработках, предоставленных компанией Facebook . Ранее, при удалении строк из InnoDB они лишь помечались удалёнными и становились доступны для новых записей без фактического освобождения блоков на диске и без возвращения дискового пространства системе. Выполнение "OPTIMIZE TABLE" решает указанную проблему, но путём полного перестроения таблицы с копированием имеющихся данных на новое место, т.е. требует наличия большого объёма свободного дискового пространства. После включения в файле конфигурации поддержки дефрагментации (innodb-defragment=1), выполнение команды "OPTIMIZE TABLE" не приводит к копированию в новые таблицы, а реализуется через механизм перемещения записей;
Реализован "оптимистичный" режим параллельной репликации, который значительно упрощён по сравнению с появившимися в MariaDB 10.0 средствами параллельной репликации slave-серверов. В частности, обеспечена возможность параллельного применения к slave-серверу любых операций INSERT/UPDATE/DELETE, даже если они пока не завершены на master-сервере;
Возможность проверки степени надёжности задаваемого пароля при помощи плагинов simple_password_check и cracklib_password_check;
Внесена порция оптимизаций производительности, позволивших снизить нагрузку на CPU и увеличить эффективность работы на многоядерных системах. Тестирование показало прирост числа обрабатываемых транзакций от 135 до 190% и возможность обработки более миллиона OLTP-операций в секунду;
Добавлены команды "EXPLAIN FORMAT=JSON" и "ANALYZE FORMAT=JSON", при которых вывод с оценкой характеристик запроса формируется в формате JSON. Штатный вывод команды ANALYZE теперь походит на вывод EXPLAIN, но включает полученные в результате выполнения запроса данные (число прочитанных строк и т.п.);
Средства для пространственной привязки (Spatial Reference) данных геоинформационных систем. Реализация новых функций для работы с пространственными координатами: ST_Boundary, ST_ConvexHull, ST_IsRing, ST_PointOnSurface, ST_Relate;
Поддержка выражений "IF EXISTS", "IF NOT EXISTS" и "OR REPLACE" в директивах "CREATE DATABASE", CREATE FUNCTION UDF", CREATE ROLE", CREATE SERVER", CREATE USER", CREATE VIEW", DROP ROLE", DROP USER", CREATE EVENT", "DROP EVENT" CREATE INDEX", "DROP INDEX" CREATE TRIGGER" и "DROP TRIGGER";
Поддержка команд SHOW и FLUSH для плагинов, например, "SHOW LOCALES", "SHOW QUERY_RESPONSE_TIME", "FLUSH QUERY_RESPONSE_TIME";
Поддержка директивы "SET DEFAULT ROLE", позволяющей определить роль по умолчанию, применяемую ко всем новым соединениям;
Поддержка systemd.

Начиная с октября 2011 года мы проводим апгрейд наших серверов баз данных, с целью замены MySQL на новую версию: MariaDB.

Что такое MariaDB?

MariaDB - это альтернативная MySQL СУБД, которую разрабатывает автор MySQL Michael "Monty" Widenius. Основная цель проекта MariaDB - создание полностью бинарно совместимой с оригинальной MySQL версии СУБД, которая при этом будет иметь значительное количество улучшений в коде, влияющих на производительность. MariaDB разрабатывается как drop-in замена для MySQL, полностью имитируя поведение MySQL.

Почему вообще Monty решил сделать клон своего же детища? Дело в том, что права на MySQL принадлежат компании MySQL AB, которую сначала купили Sun Microsystems, а затем уже Sun продались корпорации Oracle. В итоге Monty решил уйти из Oracle и сделать, в некотором смысле, MySQL "на стероидах".

MariaDB: что в ней есть нового?

MariaDB версий 5.1, 5.2 и 5.3 (beta) базируется на коде MySQL 5.1, но с рядом нововведений и улучшений.

Во-первых, это ряд новых движков (database engine) для хранения данных. А именно: Aria - альтернатива таблицам MyISAM, более быстрая и устойчивая к сбоям. Таблицы Aria используются в MariaDB для внутренних нужд, в частности все temporary tables работают именно на движке Aria, за счет чего в ряде случаев получилось добиться значительно большей производительности на сложных запросах. Кроме того, таблицы InnoDB заменены на XtraDB (альтернатива InnoDB от компании Percona), так же более быстрые, чем оригинал, и более устойчиывые к сбоям.

Кроме того, в MariaDB переписана порядка трети оригинального кода MySQL, благодаря чему удалось избавиться от многих узких мест MySQL, улучшить работу на многопроцессорных системах и конечно же повысить стабильность.

Так же в MariaDB появился новый способ доступа к данным InnoDB - HandlerSocket. HandlerSocket в каком-то смысле является альтернативой memcached. Через интерфейс HandlerSocket с данными в таблицах InnoDB (XtraDB) можно работать как с набором данных "ключ-значение", где в качестве ключа выступает любой из индексов, созданных по любой из InnoDB-таблиц. По скорости работы HandlerSocket практически не уступает memcached и некоторые источники даже сообщают, что им удалось добиться большей, чем с memcached, производительности.

Сравнительные тесты

Для того, чтобы понять, стоит ли овчинка выделки и действительно ли проделанные в MariaDB оптимизации заметны на глаз, мы провели ряд сравнительных тестов. Тесты проводились на сервере в конфигурации HP ProLiant DL160 G6, 2x E5520 Xeon QC CPU (16 cores), 20 Gb RAM, H/W RAID 10: 4x 300 Gb SAS 15k RPM. В качестве теста использовалась утилита mysqlslap следующим образом:

Mysqlslap --auto-generate-sql --concurrency=$i --number-of-queries=$(($i*500)) --iterations=3

то есть мы в цикле меняем переменную $i от 10 до 200, эмулируя при этом одновременную работу от 10 до 200 клиентов, каждый из которых делает по 500 запросов к базе данных. Далее мы замеряем общее время выполнения тестов. Тесты проводились на MariaDB версии 5.1 в сравнении с MySQL тоже версии 5.1

Таблицы MyISAM

Ниже приведены графики замеров производительности MySQL (верхний график) и MariaDB (нижний) на таблицах MyISAM. По оси X изображено количество одновременно работающих клиентов, по Y - время в секундах, затраченное на тест.

Как интерпретировать результаты: чем ниже точка на графике, тем быстрее отработал тест. Судя по графику, уже начиная с 60 одновременно работающих клиентов, MariaDB отработала тесты почти в 1,5 раза быстрее, чем MySQL.

Таблицы InnoDB

Здесь ситуация аналогичная: MariaDB победила, но только перевес здесь гораздо более значительный: производительность InnoDB в MySQL в разы хуже, чем производительность XtraDB в MariaDB.

Следует так же отметить, что данный тест замерял производительность работы только с одной таблицей, поэтому роста производительности на JOIN"ах, и особенно на запросах, выполнение которых делается при помощи создания временных таблиц, на этих графиках не видно. Реально при переходе на MariaDB даже для таблиц MyISAM производительность БД может вырасти в несколько раз.

Обращаем ваше внимание, что версия 5.1 у MariaDB, на которой проводились приведенные тесты, - это первоначальная версия, содержащая минимальный набор улучшений. В реальности мы используем на серверах MariaDB 5.2, а со временем планируем перейти на MariaDB 5.3, где улучшений и оптимизаций еще больше.

Что будет теперь, когда ненавистная и даже глубоко противная истинным сторонникам открытого софта компания 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-тренд

Ты наверняка знаешь о новомодном . По сути, это отказ от традиционного сервера базы данных с его таблицами и 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, не нарушая при этом совместимости. Ты все еще сидишь на стареньком мускуле? Тогда мы идем к тебе!

Которая вскоре была сама куплена Oracle). Это довольно оправданные сомнения, о которых я поговорю немного позже. Кроме своей роли "упрощенной версии" MySQL, MariaBD также обладает несколькими новыми функциями, которые, по мнению некоторых, делают её лучше MySQL.

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

Команда разработчиков MariaDB, должно быть, знают об этом, так как они решили использовать новую схему нумерации. Самая новая версия MariDB (которая всё ещё является альфа-версией) - Maria 10.0, за которой следует младший номер устройства:

Mysql -P 3406 -u root -p Enter password: ******** Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 1 Server version: 10.0.2-MariaDB mariadb.org binary distribution Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. Type "help;" or "\h" for help. Type "\c" to clear the current input statement. MariaDB [(none)]> select version(); +------+ | version() | +------+ | 10.0.2-MariaDB | +------+ 1 row in set (0.01 sec) MariaDB [(none)]>

Люди, работающие над MariaDB, дают длинное и довольно пространное объяснение, почему они так сделали - что всё ещё разочаровывает некоторых разработчиков - но что есть, то есть. Они не могут продолжать добавлять новые функции и постоянно утверждать, что это ускоренная, полностью совместимая с MySQL версия.

Так что за новые функции? Давайте рассмотрим парочку из них.

Движок Cassandra

Одной из уникальных функций MariaDB является её движок для соединения с серверной версией СУБД Cassandra. Сам движок является просто посредником, который соединяется с сервером Cassandra, запущенным отдельно. Cassandra - это NoSQL хранилище данных, которое изначально было создано для Facebook , а затем стало проектом Apache ; хотя оно и может использоваться в кластерах без единой точки отказа, оно всё ещё не является совместимым с ACID. Вообще, если вы собираетесь использовать Cassandra в качестве движка, не ожидайте такой же скорости производительности, как у InnoDB или ExtraBD.

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

Так что эта функция может быть полезной, если вы... мм... дайте подумать... ну...

Если вы пишете программное приложение, которое требует доступа к данным в Cassandra, тогда вам, возможно, лучше использовать встроенный Cassandra API, а не MySQL. Полагаю, что если вы мучаетесь с интерфейсом командной строки MySQL и нужно взять кое-какие данные, то Cassandra может оказаться полезной - но если вы собираетесь воспользоваться этим, то не проще ли помучаться с интерфейсом командной строки Cassandra?

Так что я на самом деле не очень уверен в данном варианте использования, но именно это умерило энтузиазм по поводу данной функции у некоторых людей в блогосфере .

Движок OQGraph

Не буду слишком много о нём рассказывать, так как идея та же, что и в Cassandra: движок является просто интерфейсом вычислительного движка Open Query Graph (хранилища для организации сложных графов). Это может помочь в некоторых специализированных приложениях, хотя адаптация структур графов к SQL формату является на первый взгляд немного странной.

Одним важным улучшением, что делает MariaDB более мощной, является использование XtraDB в качестве ускоренного замещения InnoDB. Но XtraDB добавляет новые возможности масштабирования, в которых нуждаются современные приложения - и именно в этом заключается главное отличие. Oracle утверждает, что на данный момент MySQL масштабирует лучше, чем когда-либо раньше. Возможно, это так и есть, но она хороша так же, как и её движок. А если движок на практике не масштабирует так, как следует, то и MySQL не сможет сделать этого лучше.

Режим атомарной записи

Одной из главных причин, почему следует выбирать реляционную базу данных, а не обычную NoSQL, является то, что реляционная база полностью совместима с ACID. Проще говоря, если возникает какая-либо ошибка, никто не хочет, чтобы все данные исчезли. И хотя на компьютерах разработчиков ошибки - явление не частое, они всё ещё происходят во многих IT центрах. На данный момент, стандартный InnoDB/XtraDB движок для записи данных использует двойную буферизацию , чтобы гарантировать успешную запись данных в случае какого-либо сбоя. Как бы то ни было, при работе с высокоскоростными SSD устройствами (возьмём в качестве примера), двойной буфер может плохо сказаться на производительности, не давая вам возможности использовать всю скорость SSD. Какое решение? Вы можете выбрать один буфер и воспользоваться режимом атомарной записи (Atomic Writes). Попробуйте на свой страх и риск и, лучше не на производстве.

Повторюсь, функция интересная, но не настолько, чтобы убедить вас забросить MySQL и перейти на MariaDB.

Сравнение производительности MySQL и MariaDB

А сейчас я хочу обратить ваше внимание на сравнительные тесты, проведенные командой MariaDB, и добавить кое-какие комментарии. В этом блоге выдвинута интересная точка зрения: если потоков меньше 16, MySQL работает хорошо, а если их количество больше - хотя, конечно, производительность продолжает немного расти, но не так хорошо, как в других версиях, с которыми её сравнивали (включая MariaDB-5.5.28a и MariaDB-10.0.1; посмотрите график теста производительности в начале этой статьи). Это довольно часто встречающаяся проблема в параллельном программировании при попытке ориентации на несколько ядер и потоков внутри ядра. Если построенные алгоритмы верны, то вы будете ощущать преимущества по мере увеличения ядер. Проблема в том, что вам придётся использовать в своём параллельном программировании 2 метода: 1) многопотоковый на нескольких ядрах и 2) векторизацию. Эти методы являются двумя сторонами нынешнего многоядерного программирования, и ваш код должен корректно их использовать.

Одним из наиболее распространённых результатов неправильного кодирования является то, что вы будете наблюдать прирост производительности при работе с первыми 8 или 16 потоками, после чего никакого улучшения наблюдаться не будет. Если у вас возникла такая проблема, то скорее всего дело в алгоритмах. И это будет в случае или с гиперпотоками, или с аппаратными потоками. Это именно то, что мы наблюдаем в тестах MySQL. Для меня это означает наличие проблем с масштабированием в MySQL, и это повод задуматься. В том же тесте у MariaDB также наблюдались некоторые проблемы, т.к. производительность уменьшалась, но незначительно; я предполагаю, что это не касается параллельных алгоритмов.

Также я не знаю, насколько хорошо некоторые версии подходили к компьютерам, которые использовались для проведения теста. При компиляции Intel-кода, вам нужно, чтобы компилятор генерировал SIMD-код размера, подходящего для целевой машины. В случае несоответствия вы не получите ожидаемой производительности от вашего кода векторизации. Чтобы сделать это правильно, вам потребуется вставить в код нужные прагмы, затем правильно написать алгоритмы векторизации и, наконец, запустить соответствующие опции компилятора. Знаю, звучит глупо, но я видел программы, изданные с неправильными опциями чаще, чем вы думаете. В любом случае, чистый MySQL-код не был так оптимизирован для поддержки многоядерности и векторизации, как MariaDB.

Больше всего мне хотелось бы увидеть разновидность или MySQL, или MariaDB, скомпилированную специально для сопроцессора Intel Xeon Phi, где код разгружает 61-ядерный cопроцессор, а кто-то пытается раскрутить все 244 потока. К сожалению, у меня нет доступа к такой машине. Также, если вы хотите узнать больше о векторизации и параллельном кодировании, почитайте последнюю книгу сотрудников Intel Джеймса Джефферса (James Jeffers) и Джеймса Райндерса (James Reinders) "Высокопроизводительное программирование для сопроцессора Intel Xeon Phi".

Следует ли переходить?

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

Так следует ли переходить на MariaDB?

Во-первых, продумайте всевозможные риски (руководители высшего звена любят слушать про риск и пользу). Если вы перейдёте на MariaDB, возможно, вы начнёте пользоваться функциями, доступными только для MariaDB (что пока что маловероятно), а затем окажется, что вернуться назад к MySQL, не приложив усилий, не получится. Но осмелюсь предположить, что это не такой уж и риск, если учесть некоторые более масштабные проблемы.

Поразмышляйте над всеми вопросами насчёт Oracle и её планами по лицензированию MySQL. MySQL с открытыми исходниками идёт вразрез с патентованными и очень конкурентными программами. Только это является поводом для размышлений - будет ли Oracle что-либо предпринимать, чтобы как-то помешать разработке MySQL? Некоторые утверждают , что это уже происходит.

А что насчёт совместимости MySQL и MariaDB? Команда MariaDB усердно работает над тем, чтобы сделать базу данных полностью совместимой с MySQL, и они продолжают устранять ошибки в исходнике. Однако новые функции (а также схема нумерации версий) предполагают, что, несмотря на все усилия, обе платформы будут сильно различаться.

Если Oracle добавит к MySQL некоторые новые функции, которые не поддерживаются MariaDB, то очевидно, что они не будут доступными для вас. А если вы будете пользоваться функциями, отсутствующими в MySQL, вы не сможете обратно на него перейти, учитывая, что у вас были причины перейти на другую платформу. MariaDB подаёт все признаки того, что она довольно долгое время будет в ходу, что нельзя сказать о MySQL. Другими словами, даже если новые функции MariaDB могут и не быть полезными для всех, на мой взгляд, существует более чем достаточно причин, чтобы отказаться от MySQL и полностью перейти на MariaDB.

Одна маленькая ремарка перед тем, как я закончу. Некоторые блоггеры подняли хороший вопрос по поводу соглашений об обслуживании. Если кто-либо из сотрудников вашей компании взял и купил у Oracle соглашение об обслуживании, чтобы помочь вам с MySQL, возможно, чтобы избежать финансовых и правовых вопросов, возникающих при нарушении договора, вам не захочется переходить на MariaDB. Кроме этой, я больше не вижу веских причин, чтобы продолжать пользоваться MySQL.