Форки движка MySQL: MariaDB vs Percona

В данной статье будут описаны 2 популярные альтернативные замены нашего мускула MariaDB и Percona. Ху из ху? Percona используют для таблиц InnoDB, где запросы в основном идут на апдейт, добаление. MariaDB использует как InnoDB так и MyISAM. Т.е. можно сказать MariaDB имеет более обширную структуру работы.
MySQL стал собственностью Oracle, есть ли альтернативы и как быстро движение вперед?.. Вроде как обобщающего обзорчика «who is who?» еще не было. Итак, обзорчик для тех кто «не в теме»
Некоторых людей пугает, а многих просто не устраивает, что MySQL стала принадлежать Oracle. К счастью мы уже с вами живем в мире, где информация разносится со скоростью печати мысли и решения находятся молниеносно.

Майкл Видениус (Michael Widenius), основатель MySQL и основатель компании MySQL AB (которую и поглотила Sun, которую и поглотила Oracle)
Петр Зайцев — эксперт по производительности MySQL, бывший тимлидер группы High Perfomance в MySQL Inc, ведущий блога MySQLPerformanceBlog.com

Итак, какие существуют альтернативы?

Percona server — это сборка MySQL (от Петра Зайцева и ко) с включенным по умолчанию XtraDB storage engine. Отличается от MySQL+InnoDB plugin лучшей производительностью/масштабируемостью, особенно на современных многоядерных серверах. Также улучшена функциональность — больше всякой полезной для оптимизации статистики и пр. Собирается в вариантах базирующихся на MySQL 5.0 и 5.1. Полностью совместим с таблицами innodb, то есть можно переходить от innodb к xtradb и обратно без проблем (если не использовать некоторые специфичные для xtradb функции, типа меньшего размера страницы).

Хранилище XtraDB основано на коде InnoDB-plugin, полностью совместимо с ним, но отличающийся заметно более высокой производительностью, благодаря интеграции патчей от компаний Google и Percona. В частности, в XtraDB улучшен механизм работы с памятью, улучшена работа подсистемы ввода/вывода InnoDB, добавлена поддержка нескольких потоков чтения и записи, поддержка управления пропускной способностью, реализация упреждающей выборкой данных (read-ahead), адаптивная установка контрольных точек (adaptive checkpointing), расширены возможности по масштабированию для больших проектов, система организации блокировок адаптирована для работы на системах с большим числом CPU, добавлены дополнительные возможности для накопления и анализа статистик

http://www.percona.com/docs/wiki/repositories:yum

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

Сборка от Монти, синхронизирована с кодовой базой MySQL и полностью с ней совместим, т.е. может выступать в качестве прозрачной замены MySQL 5.1, обладая при этом рядом расширенных функций, включая оптимизации производительности и поставляясь с набором дополнительных движков хранилищ:

-Новые хранилища данных:
Aria (ранее Maria) — основанное на MyISAM высоконадежное хранилище, отличающиеся повышенной устойчивостью и сохранению целостности данных после краха, при полной совместимости с MyISAM
OQGRAPH (хранилище для организации сложных графов)
Sphinx — хранилище для построения поисковых движков
PrimeBase XT — описание на русском
В качестве замены InnoDB используется движок XtraDB
FederatedX — позволяет организовать обращение к удаленным таблицам как к локальным
-Патчи MyISAM движка — Сегментированный кэш (при высоких нагрузках дает существенный прирост)
-Виртуальные столбцы
-Ликвидация таблиц — новый вид оптимизации запросов с использованием JOIN
-Пул потоков — теперь на одно соединение можно открыть больше одного потока
-Улучшены Механизмы отладки медленных запросов

Готовые бинарные сборки MariaDB доступны для платформ Windows, Debian, Ubuntu, RHEL 5, CentOS 5 и Solaris x86.


Понравилась статья? Поделись с остальными.

Комментарии закрыты.