MariaDB - программа для работы с базами данных. Является свободно распространяемым приложением, которое было создано, как альтернатива лицензионного MySQL. По принципу своей работы очень схожа с идентичным продуктом компании Oracle. СУБД поддерживает стандартные функции и форматы: myisam, blackhole, csv. Поддерживает такие же клиентские интерфейсы API, протоколы и структуры, как и MySQL. Все коннекторы (PHP, Perl, Python, Java, .NET, MyODBC, Ruby) отлично взаимодействуют с системой управления БД. Время выполнения запроса значительно меньше, чем у лицензионного аналога. Репликации протекают быстрее и безопаснее. Улучшен асинхронный ввод-вывод для таблиц InnoDB. Поддерживает сегментирование кеша для MyISAM. Это позволяет ускорить работу с MyISAM-таблицами в 4 раза.
- Позволяет работать с различными базами данных.
- Представляет собой систему управления базами хранения данных.
- Поддерживает множество клиентских приложений и API.
- Отлично подключается к большинству коннекторов.
- Позволяет создавать различные базы для хранения информации.
- Механизм хранения Aria позволяет быстрее обрабатывать сложные запросы.
- Поддерживает функцию «Убить все запросы для пользователя».
- Имеет богатый набор улучшенных функций.
- Имеет улучшенный асинхронный ввод-вывод для таблиц MyISAM.
- Поддерживает параллельные репликации.
- Имеет множество оптимизированных параметров.
- Отличное решение для веб-разработчиков, предпочитающих свободно распространяемое ПО.
- Есть поддержка русского языка.
- Процессор с тактовой частотой 1200 MHz или более мощный.
- Оперативная память 256 Мб или больше.
- Свободное место на жёстком диске от 636 Мб.
- Архитектура с разрядностью 32 бит или 64 бит (x86 или x64).
- Операционная система Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10
СУБД: Таблицы сравнения
| Название программы | На русском | Дистрибутивы | Инсталлятор | Популярность | Размер | Индекс |
| ★ ★ ★ ★ ★ | 286.7 Мб | 100 | ||||
| ★ ★ ★ ★ ★ | 0.5 Мб | 97 | ||||
После полутора лет разработки и пяти предварительных выпусков сформирован первый стабильный релиз новой ветки СУБД 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.
От автора: система управления базами данных стала неотъемлемой частью разработки динамического веб-продукта. С ее помощью можно систематизировать весь массив необходимых файлов. Все это нужно для быстрого доступа и оптимизации работы приложения или сайта. Но чтобы полностью освоить все, пусть даже самые популярные, потребуются десятилетия. Следует определится, какую вы будете использовать, изучать, и прокачивать свой скилл. Самое популярное сравнение – MariaDB vs MySQL. На них мы сегодня и сконцентрируемся. Не забудем и продукты, которые только набирают популярность, но уже обладают существенным конкурентным преимуществом.
Реляционная система
До того, как были изобретены подобные решения, не могло быть и речи о том, чтобы создавать массивные продукты. Даже те машины, которые имели хороший объем физической и оперативной памяти, не могли обработать Big Data, если она хранилась в относительно хаотичном порядке – в виде файлов. В начале восьмидесятых годов была выпущена первая РСУБД, разработчиками которой стали IBM.
На первый взгляд, создание базы данных кажется весьма тривиальной задачей. Внешне все выглядит просто, как большая таблица, в которой разные типы информации размещены в своих колонках. На самом деле, этому изобретению предшествовал целый ряд математических дискуссий и попыток разработки. Вся суть была не в том, чтобы сделать простую базу данных, а ту, в которой переменные будут зависеть друг от друга. Наиболее точное описание будущей БД дал доктор Кодд, который и сформировал 12 правил реляционной базы. Кстати, их 13 . Они до сих пор используются для разработки реляционной базы данных.
Реляционная система управления базой данных не должна использовать никаких других методов управления, кроме реляционных. Все это может показаться простым только для тех, кто понимает математические термины, как минимум, на идейном уровне. Между каждой атомарной единицей данных должна быть реляционная связь, что значительно лучше, чем просто файлы, раскиданные по физическому хранилищу.
JavaScript. Быстрый старт
Как мы и говорили, СУБД – это таблица, и другой структуры не может быть у системы. Зато данные в таблице могут быть самого разного типа. Некоторые СУБД поддерживают не так много типов, некоторые вводят даже новые, для информационных технологий. Это и булевы, и стринги, и данные с плавающей точкой, и много других. И все эти данные связаны между собой согласно реляционной модели.
Тем не менее, чтобы прописать данные в строку, ей нужно задать тип данных. Очень похожую процедуру вы проделываете с ячейками в Exel и подобных программах. Существуют, конечно, и исключения из этих правил, но это уже тема для целой книги, а не нашего сравнения баз данных.
Когда речь идет о веб-сайтах и приложениях, то в ячейках оказываются данные о пользователях ресурса, само содержимое, продукция и что-угодно. Цель базы данных здесь в том, чтобы оперативно предоставлять эту информацию по запросу пользователя: серверный скрипт, в обмен на клиентский.
Преимущества и недостатки СУБД
Согласитесь, если бы СУБД имели больше недостатков, чем преимуществ, никто бы не использовал их так активно. Если провести сравнение файловой системы и построенном на ней сайте, то вы увидите, насколько более плавно и эффективно работает система управления базами данных. Именно потому мы начнем с тех моментов, над которыми предстоит работать всем без исключения системам, пусть это будет MariaDB или MySQL.
Среди часто обсуждаемых недостатков современных систем управления базами данных:
нелегко освоить. Чтобы работать с Photoshop, вам необходимо познакомиться с основными инструментами этого ПО и научится их использовать. Понимать, как работает сама программа необязательно. Этого нельзя сказать о СУБД. Понимать принципы работы MySQL – значит разбираться в базах данных. Если вы пытаетесь действовать по шаблону, то, скорее всего, разработку ждет неудача. Неизвестно, что лучше: не понимать СУБД в принципе, или понимать ее неправильно;
стоимость. Сама система управления базами данных может не стоить очень много, но обслуживание базы данных, приобретение стороннего ПО и прочие. Даже разместить обширную базу данных на хорошем хостинге стоит денег.
вес. Одни только файлы для высокофункционального приложения будут весить немало. А если обернуть их в базу данных, объем существенно возрастет, ведь теперь файлы имеют некоторые функции, находятся в логической связи и вызываются скриптами. Все это стоит не только денег, но и памяти на сервере. Это особенно ощутимо, если сервером служит персональный компьютер разработчика.
централизованное размещение. Только в последние годы, разработчики начали использовать распределённый реестр для хранения файлов. Когда файлы находятся в пределах одной базы данных, они уязвимы.
Благо, большинство этих недостатков перекрываются преимуществами СУБД. Если спросить веб-программистов о том, что лучше: файлы или СУБД, ответ будет очевиден. Система открывает массу возможностей, которые недоступны ни для одной файловой системы.
Во-первых, это экономия памяти. Хоть и сама СУБД занимает определённое место, она не дает размножатся лишней информации. Никакого избытка, никаких файлов-дублей. В то же время, та информация, которая должна храниться в избытке, хранится именно таким образом. Как мы и говорили, это сложная математическая модель, которую трудно понять рядовому разработчику.
Важно, что СУБД позволяет избежать двойных истин. Система самостоятельно отбирает элементы, которые дают информацию одного рода и следит за тем, чтобы они не противоречили друг другу. Получается, что при том же объеме, продукт получает значительно больший объем информации.
Большую роль играют системы управления базами данных при совместной разработке. Обеспечить групповой доступ к дереву файлов довольно трудно, соблюдая все меры предосторожности. Но, вы можете обеспечить санкционированный доступ к СУБД ограниченному кругу лиц, без потерь для системы безопасности.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Кстати, о безопасном хранении. Сегодня трудно реализовать хранение данных лучше, чем с современной СУБД. Внедрение АБД позволяет определить необходимые меры безопасности: что может быть лучше? К тому же, новые инструменты для защиты базы данных выходят ежедневно. Доступ, как правило, осуществляется через форму запыления, но при достаточных навыках, вы сможете реализовать все: от антропометрии до двухфакторной аутентификации. Особенно это применимо к open-source СУБД, которой является MariaDB (о ней позже).
Трудно представить что-то лучше, в плане резервного копирования, чем системы управления базами данных. Если вы храните приложение в файлах, значит сохранность данных лежит в ваших руках. Вы вынуждены заботиться о том, чтобы вовремя создать бекапы и необходимые копии. СУБД может делать это с установленной периодичностью и переносить информацию на внешний носитель или в облако.
MySQL: заслуженный успех
Однозначно, это самая популярная из всех существующих СУБД. На ней строят не только веб-приложения и сложное программное обеспечение: учет материалов в библиотеке вашего города, скорее всего, реализован через MySQL или MSSQL. Функциональность этой системы заставляет конкурентов придумывать все новые и новые решения. Но и сами разработчики не отстают: последняя версия ПО вышла совсем недавно. Свою периодичность они не прерывают уже на протяжении более чем двадцати лет.
Ранее этой разработкой владела компания Sun Microsystems, которая подарила нам Java и много других инструментов разработки. В 2010 все продукты, вместе с MySQL, перешли компании Oracle. Она осуществляет поддержку СУБД и по сей день.
vИзначально эта система была разработана одноименной компанией в 1995 году. Создатели использовали самые быстровыполнимые языки программирования: C, C++ и HTML. Таким образом, разработчики получили в распоряжение стабильную и быструю СУБД с постоянной поддержкой. Сегодня MySQL входит в состав, так называемых «джентельменских наборов», которые состоят из сервера, базы данных и скриптового языка программирования.
Однозначным преимуществом MySQL перед конкурентами можно назвать используемость. Как всегда, чем более популярно ПО, тем легче с ним работать. Все баги обнаруживаются быстро, так же быстро и исправляются. Не стоит забывать и о том, что это софт для программистов и разработчиков, который развивается быстро благодаря сообществу. Постоянно появляются новые плагины и различные расширения для MySQL.
Устанавливать MySQL предельно просто. Благодаря наличию GUI – графического интерфейса пользователя, это превращается в обычную установку ПО. То же самое касается и инсталляции дополнений к СУБД.
Нельзя не упомянуть о том, что MySQL – одна из наиболее кроссплатформенных СУБД. Чувствуется рука компании Sun, для которой запуск ПО «хоть на калькуляторе» был приоритетом. Что говорить о масштабируемости: почти все самые больше ресурсы, с которыми вы работает в сети, построены на основе MySQL. Хотя существуют и более профессиональные варианты, например, PostgreSQL, о котором мы не забыли.
«Мария», как лучшее в СУБД
Как и у всех open-source проектов, у MySQL случился удачный форк, который получил название MariaDB. И материнская СУБД, и ее ответвление, носят имена дочерей создателя: Мю и Мария. Эту систему привыкли называть альтернативой MySQL, однако это в корне неверное заявление. Хоть и споры о том, что лучше, Maria или My до сих пор продолжаются.
Целью разработчиков «Марии» было создать продукт, полностью совместимый с MySQL, но значительно улучшенный. К примеру, движком для хранения данных в MySQL была MyISAM. В Марии – это Aria, которая подарила СУБД большую производительность, в сравнении с основным проектом. И, хотя MariaDB основана на MySQL, последние версии содержат не более чем 25% оригинального кода.
Мария может похвастаться более высокой производительностью в целом. Особенно это касается перекодировки символов. На высоких объемах информации коэффициент достигает более чем 2%. Отладочный код тоже оптимизирован, по сравнению с MySQL. В целом, разработчики отмечают высшую скорость разработки, чем мог выдать «родитель». Сообщество, которое трудится над MariaDB обещает еще большие улучшения.
Кроме того, сам пользователь может улучшать и оптимизировать работу Марии. Что отличает эту СУБД от всех остальных, так это полноценный open-source: никаких закрытых элементов или модулей, все в доступе. Играть с кодом можно неограниченно, как и делать предложения по изменению сообществу, которое и разрабатывает MariaDB.
Заявка на победу от Postgres
PostgreSQL – это еще одна система управления базами данных, только уже не реляционная, о объектно-реляционная. Это значит, что пользователь сам может создавать объекты для операций, куда могут входить различные данные. Она полностью бесплатна и наиболее гибка. Некоторые разработчики называют PostgreSQL самым профессиональным решением, из всех которые существуют на рынке. Эта СУБД появилась из некоммерческого университетского проекта, созданного в Беркли, который называлась Postgres. Эта система разрабатывалась долгих восемь лет и поддерживается до этого дня.
Как бывает с такими продуктами, она получилась «от программистов для программистов» – невероятно функциональной, но слишком сложной в освоении для обычного разраба. Изначально СУБД даже имела свой собственный язык запросов, но впоследствии от этой идеи отказались, оставив тривиальный «сиквел». Несмотря на энтузиазм независимых разработчиков, PostgreSQL не так хороша, какой ее любят называть. До сих пор в исходном коде находят проблемные места.
По масштабируемости PostgreSQL не уступает, если сравнивать с MySQL и MariaDB. На основе этого ПО строятся массивные проекты по обработке Big Data, так как ее стабильности доверяют разработчики. Несколько вариантов интерфейса делают продукт доступным для персонализации.
Но до массового продукта PostgreSQL еще далеко. Дело в том, что эта система слишком сложная для простого разработчика. Даже если взять в руки документацию, вы не получите ответов на все вопросы, включая наиболее логичные. Также, смущает скорость выполнения запроса в PostgreSQL.
Эта СУБД отлично подходит для корпоративных решений. К примеру, база данных для IT-компании, где ее поддержкой может заняться каждый из разработчиков. Тем более, что PostgreSQL полностью бесплатна.
На этом у нас все. Помните, что в таких сложных решениях как СУБД, трудно назвать лидера. По используемости – это MySQL, по расширяемости – MariaDB и PostgreSQL. Как только мы получим продукт, который станет панацеей для всех случаев, мы обязательно расскажем об этом .
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
И сейчас встал выбор СУБД для хранения основных данных. Начинал разработку на 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 была разработана фино-шведской компанией 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 теперь используют ее по умолчанию в своих репозиториях. Оригинальная версия может понадобиться только в очень редких случаях.