Что будет теперь, когда ненавистная и даже глубоко противная истинным сторонникам открытого софта компания 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, не нарушая при этом совместимости. Ты все еще сидишь на стареньком мускуле? Тогда мы идем к тебе!
Вы все еще используете 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
После полутора лет разработки и пяти предварительных выпусков сформирован первый стабильный релиз новой ветки СУБД MariaDB 10.2, в рамках которой развивается ответвление от 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.2:
- Добавлена экспериментальная поддержка движка хранения MyRocks, разработанного Facebook на базе системы хранения RocksDB, оптимизированной для Flash-накопителей. В хранилище MyRocks применяются страницы данных плавающего размера, позволяющие избежать выравнивания по фиксированной границе блока, и модель хранения данных в форме лога (Log Structured Merge Trees), допускающая только дополнение (чистка производится сборщиком мусора). В процессе выполнение запросов в несколько раз сокращено число операций последовательного чтения/записи, что привело к увеличению производительности по сравнению с InnoDB на 20-30% на SDD и до 6 раз на НЖМД при нагрузке с большим числом операций случайной записи. Кроме того, MyRocks позволяет на 50% сократить размер БД по сравнению со сжатым хранилищем InnoDB и в 3.5 раза по сравнению с InnoDB без применения сжатия. Из недостатков MyRocks можно отметить отсутствие поддержки внешних ключей и полнотекстовых индексов;
- Добавлена поддержка оконных функций, задаваемых ключевым словом OVER и позволяющих совершить вычисление над набором строк, связанных с текущей строкой. По аналогии с агрегатными функциями оконные функции позволяют обратиться к другим строкам в процессе обработки результата запроса, но в отличие от агрегатных функций они не группируют результат в одну строку;
- Поддержка общих табличных выражений (выражение «WITH») и рекурсивных общих табличных выражений («WITH RECURSIVE»). Секцию WITH можно использовать для определения подзапросов как локальных временных таблиц, на которые можно много раз ссылаться в запросе. «WITH RECURSIVE» позволяет обращаться к собственному результату, например, можно организовать обход дерева в процессе выполнении запроса;
- Добавлено выражение «CONSTRAINT… CHECK» в блоке «CREATE TABLE» для задания ограничений столбца;
- Реализована возможность указания выражений в блоке DEFAULT, например «b int DEFAULT (a+1)». Обеспечена поддержка указания значений DEFAULT для полей BLOB и TEXT;
- Хранилище InnoDB обновлено до выпуска из состава MySQL 5.7.18 и задействовано по умолчанию (ранее по умолчанию предлагалось ответвление от InnoDB — XtraDB, смысл использования которого потерялся после того, как в InnoDB реализовали большинство основных возможностей XtraDB). В InnoDB добавлена поддержка пространственных индексов (spatial index);
- Добавлено выражение «SHOW CREATE USER», показывающее полное выражение «CREATE USER», использованное для создания указанного пользователя;
- Для выражения «CREATE USER» реализованы опции для ограничения потребления ресурсов и настройки tls/ssl. Например, теперь можно ограничить максимальное число запросов или соединений в час;
- Представлено новое выражение «ALTER USER», позволяющее внести изменения в учётную запись существующего пользователя;
- Сняты многие ограничения для виртуально вычисляемых столбцов;
- Добавлена поддержка выражения «EXECUTE IMMEDIATE» для запуска динамического SQL-выражения, созданного на лету;
- В оператор PREPARE добавлена возможность использования большинства выражений;
- Добавлены функции для работы с данными в формате JSON;
- Добавлен плагин аутентификации, использующий алгоритм ed25519 для хранения паролей;
- В состав сборок для Windows, CentOS, RHEL и Fedora добавлен плагин для расшифровки ключей, используемых в Amazon Web Services (AWS) Key Management Service (KMS), для их последующего использования для шифрования данных в БД;
- Появилась возможность привязки нескольких разных триггеров к одному событию;
- Добавлена поддержка отложенной репликации, при которой состояние slave-сервера на заданный промежуток времени отстаёт от master-сервера;
- Переработана реализация выражения ANALYZE TABLE, которое теперь не блокирует таблицу во время сбора статистики;
- Библиотека wsrep, используемая для организации синхронной multi-master (active-active) репликации Galera, обновлена до выпуска 25.3.20;
- Обеспечено формирование пакетов для Ubuntu 17.04;
- В mysqldump добавлена опция «—add-drop-trigger», воспроизводящая функциональность MySQL 5.6 по добавлению в SQL-дамп выражения для удаления триггера перед его созданием;
- Добавлен скрипт mysqlbinlog для организации непрерывного бэкапа бинарного лога;
- Добавлена поддержка OpenSSL 1.1 и LibreSSL;
- Добавлены переменные innodb_deadlock_detect и innodb_stats_include_delete_marked для отключения система определения взаимных блокировок и учёта записей, помеченных как удалённые, при расчёте статистики;
- Добавлена переменная read_binlog_speed_limit, задающая ограничение скорости с которой slave-сервер читает бинарный лог master-сервера;
- Удалена старая клиентская библиотека, поставляемая под лицензией GPL, на смену которой пришла новая библиотека, имеющая лицензию LGPL.
Которая вскоре была сама куплена 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.
MariaDB - Desarrollador Monty Program Ab http://mariadb.org Información general Lanzamiento 22 de enero de 2009 … Wikipedia Español
MariaDB - Entwickler Monty Program AB (bis Februar 2008: MySQL AB, bis Januar 2010: Sun Microsystems) Aktuelle Version MariaDB 5.2.6 (12. Mai 2011) Betriebssystem Unix, Linux, Windows … Deutsch Wikipedia
MariaDB - Environnements Unix, Windows, Solaris Type système de gestion de base de données … Wikipédia en Français
MariaDB - Developer(s) Monty Program Ab Initial release 22 January 2009 (2009 01 22) Stable release 5.2.9 (September 22, 2011; 5 … Wikipedia
MySQL - Developer(s) MySQL AB (A subsidiary of Oracle) Initial release May 23, 1995 (1995 05 23 … Wikipedia
Comparison of relational database management systems - Programming language comparisons General comparison Basic syntax Basic instructions Arrays Associative arrays String operations … Wikipedia
Michael Widenius - Ulf Michael Widenius Michael Monty Widenius Born March 3, 1962 (1962 03 03) (age 49) Helsinki, Finland … Wikipedia
Percona XtraDB Тип СУБД (Storage Engine для MySQL) Первый выпуск 16.12.2008 Последняя версия 10.1 (16.05.2010) Лицензия GPLv2 Сайт … Википедия
HeidiSQL - The main view of an active session in HeidiSQL, with MySQL Databases (left) and contained Tables (right) … Wikipedia
Fork (software development) - In software engineering, a project fork happens when developers take a legal copy of source code from one software package and start independent development on it, creating a distinct piece of software. The term implies a split in the developer… … Wikipedia
Книги
- Базы данных. Практическое применение СУБД SQL и NoSOL-типа для применения проектирования информационных систем
- Базы данных. Практическое применение СУБД SQL и NoSOL-типа для применения проектирования информационных систем. Гриф МО РФ , Мартишин С.А.. Учебное пособие предназначено для изучения практического применения СУБД SQL и NoSQL-типа при проектировании информационных систем. Проведены аналогии между базами данных SQL и NoSQL-типа.…