Стабильный выпуск СУБД MariaDB 10.117.10.2015 19:15

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

С ранее реализованными возможностями MariaDB и отличиями от MySQL можно познакомиться в тексте анонса MariaDB 10.