Вы все еще используете 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
Оригинальная версия MySQL была разработана фино-шведской компанией MySQL AB, которую основали Джвид Ахмарк, Аллан Ларссон и Майкл Монти. Первая версия MySQL появилась в 1995 году. Изначально она предназначалась для личного пользования, но спустя несколько лет превратилась в базу данных корпоративного уровня.
В январе 2008 Sun Microsystems приобрела MySQL AB за 1 миллиард долларов. Вскоре после этого, Oracle купила Sun Microsystems с разрешения Европейской комиссии, которая изначально опасалась, что такое решение повредить свободному проекту MySQL, поскольку он был прямым конкурентом СУБД Oracle. Из-за недоверия к стратегии развития MySQL был создан форк под названием MariaDB.
Шли годы и за это время MariaDB начала использоваться во многих дистрибутивах Linux по умолчанию. Она используется для обеспечения работы большинства сайтов интернета. В этой статье мы попытаемся выполнить сравнение MySQL vs MariaDB и разобраться почему вторая лучше первой и когда нужна именно оригинальная MySQL.
В отличие от многих других проектов с открытым исходным кодом полученных от Sun Microsystems, Oracle до сих пор развивает MySQL. После того как много разработчиков подали в отставку, были наняты новые люди. Но разработка новых версий MySQL ведется закрыто. Исходный код доступен только команде разработчиков и выгружается в публичный репозиторий только после завершения работы. Все решения обсуждаются внутри компании
MariaDB разрабатывается полностью открыто, все решения и новые идеи касаемо развития могут свободно обсуждаться в email рассылке, а также системе сообщений об ошибках. Помочь в разработке MariaDB очень легко, патчи от пользователей принимаются также, как и от разработчиков. В целом MariaDB развивается более активно.
Из-за раскрученности бренда у MySQL все еще есть большое сообщество, но все больше и больше проектов переходят на MariaDB. Такие известные корпоративные дистрибутивы, как REHL 7 и SLES 12 уже используют MariaDB, а это значит, что в сражении MySQL или MariaDB победит последняя.
2. Частота релизов
Политика Oracle - выпускать обновления безопасности для всех своих продуктов каждые три месяца. Но выход новой версии MySQL запланирован каждые два месяца. Это часто приводит к тому, что обновления продукта и обновления безопасности не синхронизируются.
Разработчики не успевают закрыть все сообщения об ошибках и уязвимости, в результате чего база данных может оставаться уязвимой несколько месяцев. Еще одна проблема MySQL в том, что обновления безопасности очень расплывчаты. Если администратор не может просто обновить программу до новой версии, то создать бэкпорт сложно.
MariaDB выпускает обновления программы и обновления безопасности синхронизировано, поэтому все ошибки успевают исправить. Все исправленные CVE задокументированы и любой пользователь может узнать что изменилось в новой версии.
4. Возможности и функциональность
В целом MariaDB развивается быстрее и имеет больше возможностей. Эти возможности касаются оптимизации, улучшения работы с памятью, и много другого. Обычно, со временем, эти возможности переносятся в MySQL. Например, та же поддержка GIS появилась в MariaDB раньше, чем в MySQL. Среди прочего MariaDB имеет множество улучшений производительности Inodb, MyISAM и движка обработки запросов, поддерживает GIS, ликвидацию таблиц, виртуальные и динамические колонки, репликацию с несколькими источниками, роли и многое другое.
Но у MariaDB есть и свои минусы, она не поддерживает некоторые возможности, которые есть в MySQL. А именно, MariaDB несовместима с синтаксисом JSON MySQL, не поддерживаются плагины ngram, MeCab, MySQL X, а также пространства таблиц, которые позволяют присваивать данные нескольким таблицам одновременно. Но разработчики активно работают над исправлением недостатков.
Для тех, кого интересуют кластеры MySQL будет интересно то, что в MariaDB используется новая система репликации Galera, прием ее работа отличается от стандартного master-salve. Galera разрабатывается с 2007 года, но она никогда не включалась в официальную версию MySQL.
5. Поддержка движков хранения данных
Система управления базами данных MariaDB поддерживает намного больше движков для хранения данных. Большинство этих движков доступны в качестве плагинов для MySQL, но в MariaDB они включены в официальный релиз. Это означает, что движки правильно интегрированы и будут хорошо работать. Вот список поддерживаемых движков:
- Aria;
- XtraDB - улучшенная версия InnoDB;
- FederatedX - улучшенная версия Federated;
- OQGRAPH;
- SphinxSE;
- IBMDB2I;
- TokuDB;
- Cassandra;
- CONNECT;
- SEQUENCE;
- Spider;
- ColumnStore;
- MySIAM.
Напомню, что оригинальная MySQL поддерживает по умолчанию только три типа таблиц - Aria, MySIAM и InnoDB. Это важный аспект в выборе MySQL или MariaDB.
6. Имя и нумерация версий
Эти отличия MariaDB от MySQL не столь важны, но, возможно, они будут кому-то интересными. Имя MySQL было дано в честь первой дочери одного из разработчиков - Майкл Монти, ее зовут My. Разработку MariaDB продолжил тот же человек и на этот раз программа была названа в честь его младшей дочери - Марии.
Что касается версий, то изначально, до версии 5.6 версии MariaDB нумеровались синхронно до версий MySQL, на которых они были основаны. Но когда накопилось достаточно изменений и за основу стал браться код MariaDB номера версий было принято поменять на 10. С того момента нумерация MariaDB выполняется только так.
Выводы
В этой статье мы сделали сравнение MySQL vs MariaDB. По большинству параметров MariaDB намного лучше, чем MySQL, поэтому не зря большинство дистрибутивов Linux теперь используют ее по умолчанию в своих репозиториях. Оригинальная версия может понадобиться только в очень редких случаях.
Которая вскоре была сама куплена 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.
И сейчас встал выбор СУБД для хранения основных данных. Начинал разработку на MySQL, но сейчас не уверен в выборе. Переезд на другую СУБД на данном этапе для меня не составит проблем (использую PDO). далек от ясного понимания что такое «высокие нагрузки» для СУБД. Просто по моим расчетам примерно через год база будет весьма увесистой (см. ниже)
Основной выбор стоит между MySQL, PostgreSQL, MariaDB. Также, возможен, но не приветствуется вариант Microsoft SQL Server на Windows Azure
Ситуация такова:
- Сложных запросов к базе нет. Максимум JOIN из двух таблиц
- Бо льшая часть запросов - чтение
- Есть одна самая важная и «главная» таблица (структура таблицы ниже под спойлером). Таблица будет расти примерно на 10-30 тысяч записей в сутки. Запись данных в эту таблицу - самое главное!
- Бо льшая часть запросов на чтение будет как раз к «главной» таблице. По этой таблице будет осуществляться поиск по любому из полей (в крайне редких случаях ~0.5% - по нескольким сразу). Поиск должен осуществляться быстро (не смотря на пункт №3)
- К «главной» таблице скорее всего будут добавлены индексы к каждому из полей сразу для двух полей (ownerID и Имя поля т.к. ownerID будет указан во всех запросах). Быстрый поиск будет нужен по любому из полей, но это не столь приоритетная задача. (Или лучше использовать Sphinx?)
- Львиная доля запросов (~80%) на чтение к «главной» таблице - простые select"ы по индексам from и personalID с limit = 20. Остальные запросы по любым другим полям по индексам (которых пока нет) ownerID и Имя поля, также с limit = 20
- Изменения данных в записях «главной» таблицы будут происходить крайне редко. Никакие записи из таблицы удаляться не будут.
- Поддержка транзакций и внешних ключей не обязательна
- Нужна возможность репликации данных типа master-slave
- Возможность шардинга на уровне СУБД приветствуется
- Крайне важна надежность БД (т.е. такой крах, как у MyISAM с ручным восстановлением сразу отпадает)
- К «главной» таблице могут добавляться новые поля. Это конечно крайне редкое явление и далеко не самое важное требование, но добавление нового столбца к таблице размером с десяток ГБ для MySQL весьма длительный процесс, а выносить новые поля в отдельную таблицу очень не хочется
- Всё это по-началу будет крутиться на таком вот выделенном сервере
- Другие таблицы будут расти медленно, и обращения к ним будут достаточно редкими, за них я не переживаю. Часто обновляемые данные у меня крутятся в redis"e
P.S. Желающих отправить меня гуглить прошу даже не отвечать. Найти информацию по сравнению актуальных версий разных СУБД мне не удалось, а изучать возможности, плюсы и минусы PostgreSQL, Microsoft SQL Server и MariaDB для человека, который с ними не работал весьма долгая задача. Да и в MySQL я далеко не эксперт, и подобный крупный проект для меня дело новое, да и возможности MySQL от версии к версии отличаются. Единственное, что я точно знаю, так это то, что таблицы типа MyISAM в MySQL мне точно не подойдут
- Вопрос задан более трёх лет назад
- 39797 просмотров
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, добавлены дополнительные возможности для накопления и анализа статистик
MariaDB - сборка от Монти, синхронизирована с кодовой базой MySQL и полностью с ней совместим, т.е. может выступать в качестве прозрачной замены MySQL 5.1, обладая при этом рядом расширенных функций, включая оптимизации производительности и поставляясь с набором дополнительных движков хранилищ:
- Новые хранилища данных:
- Aria (ранее Maria) - основанное на MyISAM высоконадежное хранилище, отличающиеся повышенной устойчивостью и сохранению целостности данных после краха, при полной совместимости с MyISAM
- OQGRAPH (хранилище для организации сложных графов)
- Sphinx - хранилище для построения поисковых движков
- PrimeBase XT - описание на русском
- В качестве замены InnoDB используется движок XtraDB
- FederatedX - позволяет организовать обращение к удаленным таблицам как к локальным
- Патчи MyISAM движка - Сегментированный кэш (при высоких нагрузках дает существенный прирост)
- Ликвидация таблиц - новый вид оптимизации запросов с использованием JOIN
- Пул потоков - теперь на одно соединение можно открыть больше одного потока
- Улучшены
