Сравнение MySQL vs 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.
1. Процесс разработки
В отличие от многих других проектов с открытым исходным кодом полученных от Sun Microsystems, Oracle до сих пор развивает MySQL. После того как много разработчиков подали в отставку, были наняты новые люди. Но разработка новых версий MySQL ведется закрыто. Исходный код доступен только команде разработчиков и выгружается в публичный репозиторий только после завершения работы. Все решения обсуждаются внутри компании
MariaDB разрабатывается полностью открыто, все решения и новые идеи касаемо развития могут свободно обсуждаться в email рассылке, а также системе сообщений об ошибках. Помочь в разработке MariaDB очень легко, патчи от пользователей принимаются также, как и от разработчиков. В целом MariaDB развивается более активно.
Из-за раскрученности бренда у MySQL все еще есть большое сообщество, но все больше и больше проектов переходят на MariaDB. Такие известные корпоративные дистрибутивы, как REHL 7 и SLES 12 уже используют MariaDB, а это значит, что в сражении MySQL или MariaDB победит последняя.
2. Частота релизов
Разработчики не успевают закрыть все сообщения об ошибках и уязвимости, в результате чего база данных может оставаться уязвимой несколько месяцев. Еще одна проблема 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 они включены в официальный релиз. Это означает, что движки правильно интегрированы и будут хорошо работать. Вот список поддерживаемых движков:
6. Имя и нумерация версий
Что касается версий, то изначально, до версии 5.6 версии MariaDB нумеровались синхронно до версий MySQL, на которых они были основаны. Но когда накопилось достаточно изменений и за основу стал браться код MariaDB номера версий было принято поменять на 10. С того момента нумерация MariaDB выполняется только так.
Выводы
В этой статье мы сделали сравнение MySQL vs MariaDB. По большинству параметров MariaDB намного лучше, чем MySQL, поэтому не зря большинство дистрибутивов Linux теперь используют ее по умолчанию в своих репозиториях. Оригинальная версия может понадобиться только в очень редких случаях.
MySQL vs MariaDB
Начиная с октября 2011 года мы проводим апгрейд наших серверов баз данных, с целью замены MySQL на новую версию: MariaDB.
Что такое MariaDB?
Почему вообще Monty решил сделать клон своего же детища? Дело в том, что права на MySQL принадлежат компании MySQL AB, которую сначала купили Sun Microsystems, а затем уже Sun продались корпорации Oracle. В итоге Monty решил уйти из Oracle и сделать, в некотором смысле, MySQL «на стероидах».
MariaDB: что в ней есть нового?
MariaDB версий 5.1, 5.2 и 5.3 (beta) базируется на коде MySQL 5.1, но с рядом нововведений и улучшений.
Кроме того, в MariaDB переписана порядка трети оригинального кода MySQL, благодаря чему удалось избавиться от многих узких мест MySQL, улучшить работу на многопроцессорных системах и конечно же повысить стабильность.
Сравнительные тесты
Для того, чтобы понять, стоит ли овчинка выделки и действительно ли проделанные в MariaDB оптимизации заметны на глаз, мы провели ряд сравнительных тестов. Тесты проводились на сервере в конфигурации HP ProLiant DL160 G6, 2x E5520 Xeon QC CPU (16 cores), 20 Gb RAM, H/W RAID 10: 4x 300 Gb SAS 15k RPM. В качестве теста использовалась утилита mysqlslap следующим образом:
Таблицы MyISAM
Как интерпретировать результаты: чем ниже точка на графике, тем быстрее отработал тест. Судя по графику, уже начиная с 60 одновременно работающих клиентов, MariaDB отработала тесты почти в 1,5 раза быстрее, чем MySQL.
Таблицы InnoDB
Здесь ситуация аналогичная: MariaDB победила, но только перевес здесь гораздо более значительный: производительность InnoDB в MySQL в разы хуже, чем производительность XtraDB в MariaDB.
Следует так же отметить, что данный тест замерял производительность работы только с одной таблицей, поэтому роста производительности на JOIN’ах, и особенно на запросах, выполнение которых делается при помощи создания временных таблиц, на этих графиках не видно. Реально при переходе на MariaDB даже для таблиц MyISAM производительность БД может вырасти в несколько раз.
Benchmark: MariaDB vs MySQL on Commodity Cloud Hardware
What we tested: Relative performance of MariaDB vs MySQL
How we tested: Multi-statement, transaction processing workload (Sysbench 90:10)
Where we tested: Amazon AWS EC2 and RDS, large to 12xlarge instances
What we conclude: MariaDB provides superior performance on commodity cloud hardware for real business workloads.
Looking back in MariaDB Server’s family tree, we find its ancestor, MySQL Server. MariaDB Community Server and MySQL Server Community Edition, both Open Source, have over the years been packaged for many of the same Linux distributions, powering application stacks behind hundreds of popular websites and applications. And both are available in the cloud.
Shared Capabilities
MariaDB Features
MariaDB Server additionally supports:
MariaDB Platform X5 further extends these capabilities with:
A Real-World Workload
Database workloads come in all shapes and sizes, and in evaluating your options it is important to start at an understandable point. In choosing a workload for benchmarking, we wanted to select something easily understood and commonly seen in business, then assess performance on a level playing field on commonly available cloud configurations — a common workload running on exactly the sort of cost-effective cloud hardware (not exotic hardware) that customers choose because it makes good business sense.
For our workload, we chose a 90% read, 10% write workload, and we drove this workload using Sysbench, one of the most popular benchmarking tools in the MySQL community.
How to Run a Sysbench 90:10
Sysbench 90:10 is an adaptation of the sysbench open source benchmark driver. This configuration of sysbench attempts to stress the underlying transaction processing capability of a database system using a mix of simple, multi-statement transaction, consisting of 9 point select statements (reads) and 1 point update statement (writes).
The following command lines document the sysbench settings used in the prepare and run commands of the test.
Measurements
In our initial tests, we compared the relative performance of MariaDB Community Server 10.5.5 vs MySQL Server 8.0.21 Community Edition using Sysbench 90:10.
The tests leverage concurrency as a variable to apply increasing load on a database. Our objective is to determine the overall capacity of a system. We do that by examining the tradeoff between throughput and latency as load (concurrency) increases. Plotting throughput versus latency as a curve we are able to see when a database configuration reaches a “capacity point” (knee of the curve). At this point, increases in load stop translating into increases in throughput and instead translate into increases in latency.
Our results with MariaDB:
Our results with MySQL:
In general, MariaDB significantly outperforms MySQL at lower scale points and continues to maintain a performance differential at higher scale. This is indicated in the charts by lower latency for MariaDB than MySQL and higher throughput from MariaDB than MySQL.
Lower latency results mean a more responsive database and ultimately a more responsive application experience for your users. Higher throughput represents an ability to perform more work per second. The fact that MariaDB exhibits both lower latency and higher throughput than MySQL on commodity cloud hardware for a real business workload (90% reads, 10% writes) means MariaDB can deliver a better user experience at lower cost.
Overlay for m5d.large :
Testing in a cloud environment comes with a certain level of variability in the performance results. It is inherent in the nature of cloud computing. In an attempt to account for this variance, the results above are the averaged results from three independent tests. The following graphics show the actual results of the individual tests, illustrating the run-to-run variance between tests and how that variance grows with scale.
After testing with databases running in EC2, we wondered if these performance characteristics would also be present in RDS. Though the latest 10.5 release series (GA in June 2020) of MariaDB Community Server is not yet available on RDS, we were able to test with MariaDB 10.4 (GA in June 2019 and added to RDS in April 2020) and compare against MySQL 8.0.20.
Overlay for db.m5.large :
Conclusion
To many, MariaDB Server is a successor to MySQL Server, having superseded its position in the application stack years ago. But for those holding on to old MySQL, we believe these results present a compelling argument that for users interested in operating real-world workloads on widely available, cost-effective commodity cloud hardware, MariaDB is the best cloud database.
You can even see this in our testing of Amazon RDS. For easy apples to apples comparison we thought we’d compare MySQL and MariaDB on the same cloud platform, systems, configured by an independent 3rd party, no further tuning and tweaking – MySQL and MariaDB on AWS RDS.
MariaDB Server is available on leading cloud providers worldwide, and for the best of the best you can find MariaDB Platform including MariaDB Enterprise Server on MariaDB SkySQL.
MariaDB против MySQL
Существует довольно много причин для того, чтобы перейти на MariaDB. Давайте посмотрим, настолько ли они веские, чтобы убедить вас это сделать.
Так что за новые функции? Давайте рассмотрим парочку из них.
Движок Cassandra
Но вы можете получить доступ к информации с помощью MySQL, добавив интерфейс, похожий на SQL, а также допуская в какой-то степени выборки, вставки, обновления, удаления и даже присоединения. Однако команда MariaDB утвержает, что движок Cassandra лучше не использовать для чего-то более существенного, чем простое использование данных.
Так что эта функция может быть полезной, если вы. мм. дайте подумать. ну.
Так что я на самом деле не очень уверен в данном варианте использования, но именно это умерило энтузиазм по поводу данной функции у некоторых людей в блогосфере.
Движок OQGraph
Не буду слишком много о нём рассказывать, так как идея та же, что и в Cassandra: движок является просто интерфейсом вычислительного движка Open Query Graph (хранилища для организации сложных графов). Это может помочь в некоторых специализированных приложениях, хотя адаптация структур графов к SQL формату является на первый взгляд немного странной.
Режим атомарной записи
Повторюсь, функция интересная, но не настолько, чтобы убедить вас забросить MySQL и перейти на MariaDB.
Сравнение производительности MySQL и MariaDB
Одним из наиболее распространённых результатов неправильного кодирования является то, что вы будете наблюдать прирост производительности при работе с первыми 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 Blog |
Следует ли переходить?
Так следует ли переходить на MariaDB?
Во-первых, продумайте всевозможные риски (руководители высшего звена любят слушать про риск и пользу). Если вы перейдёте на MariaDB, возможно, вы начнёте пользоваться функциями, доступными только для MariaDB (что пока что маловероятно), а затем окажется, что вернуться назад к MySQL, не приложив усилий, не получится. Но осмелюсь предположить, что это не такой уж и риск, если учесть некоторые более масштабные проблемы.
А что насчёт совместимости MySQL и MariaDB? Команда MariaDB усердно работает над тем, чтобы сделать базу данных полностью совместимой с MySQL, и они продолжают устранять ошибки в исходнике. Однако новые функции (а также схема нумерации версий) предполагают, что, несмотря на все усилия, обе платформы будут сильно различаться.
Если Oracle добавит к MySQL некоторые новые функции, которые не поддерживаются MariaDB, то очевидно, что они не будут доступными для вас. А если вы будете пользоваться функциями, отсутствующими в MySQL, вы не сможете обратно на него перейти, учитывая, что у вас были причины перейти на другую платформу. MariaDB подаёт все признаки того, что она довольно долгое время будет в ходу, что нельзя сказать о MySQL. Другими словами, даже если новые функции MariaDB могут и не быть полезными для всех, на мой взгляд, существует более чем достаточно причин, чтобы отказаться от MySQL и полностью перейти на MariaDB.
Одна маленькая ремарка перед тем, как я закончу. Некоторые блоггеры подняли хороший вопрос по поводу соглашений об обслуживании. Если кто-либо из сотрудников вашей компании взял и купил у Oracle соглашение об обслуживании, чтобы помочь вам с MySQL, возможно, чтобы избежать финансовых и правовых вопросов, возникающих при нарушении договора, вам не захочется переходить на MariaDB. Кроме этой, я больше не вижу веских причин, чтобы продолжать пользоваться MySQL.
MariaDB versus MySQL: Compatibility
Contents
Replacement for MySQL
Until MariaDB 5.5, MariaDB versions functioned as a «drop-in replacement» for the equivalent MySQL version, with some limitations. From MariaDB 10.0, it is usually still very easy to upgrade from MySQL.
This means that for many cases, you can just uninstall MySQL and install MariaDB and you are good to go. There is not generally any need to convert any data files.
However, you must still run mysql_upgrade to finish the upgrade. This is needed to ensure that your mysql privilege and event tables are updated with the new fields MariaDB uses.
That said, MariaDB has a lot of new options, extension, storage engines and bug fixes that are not in MySQL. You can find the feature set for the different MariaDB versions on the What is in the different MariaDB Releases page.
Drop-in Compatibility of Specific MariaDB Versions
MariaDB 10.2, MariaDB 10.3, and MariaDB 10.4 function as limited drop-in replacements for MySQL 5.7, as far as InnoDB is concerned. However, the implementation differences continue to grow in each new MariaDB version.
MariaDB 10.0 and MariaDB 10.1 function as limited drop-in replacements for MySQL 5.6, as far as InnoDB is concerned. However, there are some implementation differences in some features.
MariaDB 5.5 functions as a drop-in replacement for MySQL 5.5.
MariaDB 5.1, MariaDB 5.2, and MariaDB 5.3 function as drop-in replacements for MySQL 5.1.
Replication Compatibility
Replication compatibility depends on:
Replication compatibility details are described below for each MySQL version that is still currently supported.
For replication compatibility details between MariaDB versions, see Cross-Version Replication Compatibility.
MySQL 5.7
MariaDB Server 10.2 and later can replicate from a MySQL 5.7 primary server.
MariaDB Server does not support the MySQL implementation of Global Transaction IDs (GTIDs), so the MariaDB replica server must use the binary log file and position for replication. If GTID mode is enabled on the MySQL primary server, the MariaDB replica server will remove the MySQL GTID events and replace them with MariaDB GTID events.
MariaDB can’t make any claims about whether a MySQL 5.7 replica server can replicate from a MariaDB primary server.
MySQL 8.0
MariaDB Server cannot replicate from a MySQL 8.0 primary server, because MySQL 8.0 has a binary log format that is incompatible.
Incompatibilities between Currently Supported MariaDB Versions and MySQL
Incompatibilities between MariaDB 10.7 and MySQL 8.0
Incompatibilities between MariaDB 10.6 and MySQL 8.0
Incompatibilities between MariaDB 10.5 and MySQL 8.0
Incompatibilities between MariaDB 10.4 and MySQL 8.0
Incompatibilities between MariaDB 10.3 and MySQL 5.7
Incompatibilities between MariaDB 10.2 and MySQL 5.7
Incompatibilities between Currently Unsupported MariaDB Versions and MySQL
Incompatibilities between MariaDB 10.1 and MySQL 5.7
Incompatibilities between MariaDB 10.0 and MySQL 5.6
Incompatibilities between MariaDB 5.5 and MySQL 5.5
Incompatibilities between MariaDB 5.3 and MySQL 5.1
Incompatibilities between MariaDB 5.2 and MySQL 5.1
The list is the same as between MariaDB 5.1 and MySQL 5.1, with one addition:
For all practical purposes, MariaDB 5.2 is a drop in replacement for MariaDB 5.1 and MySQL 5.1.
Incompatibilities between MariaDB 5.1 and MySQL 5.1
In some few cases MariaDB has to be incompatible to allow MariaDB to provide more and better information than MySQL.
Here is the list of all known user level incompatibilities you may see when using MariaDB 5.1 instead of MySQL 5.1.
Old, Unsupported Configuration Options
If you are using any of the following options in your /etc/my.cnf or other my.cnf file you should remove them. This is also true for MySQL 5.1 or newer:
Replacing a MySQL RPM
After installing MariaDB you should do the following to restore your old configuration options:
Incompatibilities between MariaDB and MySQL-Proxy
A MySQL client API is able to connect to MariaDB using MySQL-Proxy but a MariaDB client API will receive progress reporting informations that MySQL-Proxy does not implement, to get full compatibility in all case just disable progress reporting on the client or server side.
Another option is to use the MariaDB MaxScale proxy, that works with both MySQL and MariaDB.