Mysql или mariadb: Сравнение MySQL vs MariaDB | Losst

Сравнение MySQL vs MariaDB | Losst

Оригинальная версия 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. Частота релизов

Политика 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 теперь используют ее по умолчанию в своих репозиториях. Оригинальная версия может понадобиться только в очень редких случаях.

что лучше, MariaDB vs MySQL

От автора: система управления базами данных стала неотъемлемой частью разработки динамического веб-продукта. С ее помощью можно систематизировать весь массив необходимых файлов. Все это нужно для быстрого доступа и оптимизации работы приложения или сайта. Но чтобы полностью освоить все, пусть даже самые популярные, потребуются десятилетия. Следует определится, какую вы будете использовать, изучать, и прокачивать свой скилл. Самое популярное сравнение – MariaDB vs MySQL. На них мы сегодня и сконцентрируемся. Не забудем и продукты, которые только набирают популярность, но уже обладают существенным конкурентным преимуществом.

Реляционная система

До того, как были изобретены подобные решения, не могло быть и речи о том, чтобы создавать массивные продукты. Даже те машины, которые имели хороший объем физической и оперативной памяти, не могли обработать Big Data, если она хранилась в относительно хаотичном порядке – в виде файлов. В начале восьмидесятых годов была выпущена первая РСУБД, разработчиками которой стали IBM.

На первый взгляд, создание базы данных кажется весьма тривиальной задачей. Внешне все выглядит просто, как большая таблица, в которой разные типы информации размещены в своих колонках. На самом деле, этому изобретению предшествовал целый ряд математических дискуссий и попыток разработки. Вся суть была не в том, чтобы сделать простую базу данных, а ту, в которой переменные будут зависеть друг от друга. Наиболее точное описание будущей БД дал доктор Кодд, который и сформировал 12 правил реляционной базы. Кстати, их 13 . Они до сих пор используются для разработки реляционной базы данных.

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

JavaScript. Быстрый старт

Изучите основы 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 на практическом примере по созданию веб-приложения

Узнать подробнее

Библиотека ORM – RedBeanPHP

Прямо сейчас посмотрите видео по RedBeanPHP!

Смотреть

Сравнение MariaDB и MySQL. Все, что вам нужно знать в 2019 году

MySQL является одной из наиболее широко используемых в мире СУБД. Это программное обеспечение бесплатно и распространяется с открытым исходным кодом. MySQL, разработанный на C/C ++, является одним из самых популярных вариантов баз данных.

СУБД была разработана шведской компанией «MySQL AB» в 1995 году. Позже MySQL AB была приобретена Sun Microsystems в 2008 году. Позже Sun Microsystems была приобретена Oracle в 2010 году. С тех пор MySQL поддерживается и управляется Oracle.

Эта статья — перевод и адаптация англоязычной статьи MariaDB vs MySQL: [2019] Everything You Need to Know.

Во время приобретения Sun Microsystems компанией Oracle некоторые из старших инженеров, которые работали над разработкой MySQL, почувствовали, что существует конфликт интересов между MySQL и коммерческой базой данных Oracle — Oracle Database Server. В результате эти инженеры создали форк базы кода MySQL и основали собственную организацию. Так родилась MariaDB.

На сегодняшний день обе базы данных пользуются большой популярностью и широко используются сообществом разработчиков. MySQL занимает № 2 среди реляционных баз данных и № 2 среди всех СУБД (№ 1 является базой данных Oracle). Напротив, MariaDB немного отстает — № 9 среди реляционных баз данных и № 14 в целом.

Преимущества MariaDB перед MySQL

В MariaDB добавлены оптимизации, которые повышают производительность СУБД по сравнению с оригинальным MySQL.

Представления

В части производительности представлений в MariaDB проделана существенная оптимизация. «Представления» — это, по сути, виртуальные таблицы базы данных, к которым можно обращаться, как к обычным таблицам базы данных. В MySQL при запросе к представлению запрашиваются все таблицы, связанные с этим представлением, независимо от того, что для запроса могут не потребоваться некоторые представления. В отличие от MySQL, в MariaDB, запрашиваются только те таблицы, которые необходимы для запроса.

Колоночное хранилище

MariaDB предоставляет еще одно мощное улучшение производительности, достигаемое с помощью нового типа таблиц, представленных не в форме построчного хранилища, а в форме колоночного хранилища. Колоночные хранилища часто используются в аналитике больших данных. MariaDB позволяет масштабировать хранилище данных до петабайтного размера, обспечивая линейное повышение производительности запросов к хранимых данным при добавлении новых серверов.

Более высокая производительность на SSD

MariaDB предоставляет механизм хранения MyRocks, который позволяет хранить данные в RocksDB. RocksDB — это встраиваемая база данных, которая была разработана для повышения производительности обработки данных, хранимых на SSD-накопителях.

Сегментированный кеш ключей

MariaDB представляет еще одно улучшение производительности — сегментированный кеш ключей. В типичном кеше различные потоки конкурируют за блокировку кэшированной записи. Когда несколько потоков конкурируют за мьютекс, только один из них может получить его, в то время как другим приходится ждать освобождения блокировки перед выполнением операции. Это приводит к задержкам выполнения в этих потоках, замедляя производительность базы данных. В случае сегментированного кэша ключей потоку не нужно блокировать всю страницу, но он может блокировать только тот сегмент, к которому относится страница. Это помогает нескольким потокам работать параллельно, увеличивая параллелизм в приложении, что приводит к повышению производительности базы данных.

Виртуальные столбцы таблицы

Интересная функция, которую поддерживает MariaDB — это виртуальные столбцы. Эти столбцы способны выполнять вычисления на уровне базы данных. Это позволяет перенести типовые вычисления с приложений в сервер СУБД. Эта функция не доступна в MySQL.

Параллельное выполнение запросов

Одна из последних версий MariaDB — 10.0 допускает параллельное выполнение нескольких запросов. Идея состоит в том, что некоторые запросы от Master могут быть переданы на выполнение на ведомые серверы (slave). Этот параллелизм в выполнении запросов, безусловно, обеспечивает MariaDB преимущество над MySQL.

Пул потоков

MariaDB также представляет новую концепцию под названием «Thread Pooling». Ранее, когда требовалось несколько соединений с базой данных, для каждого соединения открывался поток, что приводило к архитектуре «один поток на соединение». С использованием «Thread Pooling» исспользуется пул потоков, которые могут повторно использоваться. Таким образом, новый поток не нужно открывать для каждого нового запроса на подключение, что приводит к более быстрым результатам запроса. Эта функция доступна в коммерческой версии MySQL, но, к сожалению, недоступна в версии для сообщества.

Бэкенды хранения данных

MariaDB предоставляет несколько мощных механизмов хранения, которые не доступны в MySQL. Например, XtraDB, Aria и т. д. Чтобы настроить эти механизмы хранения для MySQL, вам необходимо установить их вручную.

Совместимость

Команда MariaDB гарантирует, что MariaDB сможет заменить MySQL в существующих приложениях. Фактически для каждой версии MySQL они выпускают тот же номер версии MariaDB, чтобы указать, что MariaDB обычно совместима с соответствующей версией MySQL. Это открывает возможность беспрепятственного перехода на MariaDB без каких-либо изменений в кодовой базе приложения.

Заключение

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

Если вы хотите быстро начать использовать MariaDB для тестов или продуктового применения, рассмотрите нашу статью по развертыванию MariaDB в экосистеме Docker.

MariaDB против MySQL | ИТ Блог. Администрирование серверов на основе Linux (Ubuntu, Debian, CentOS, openSUSE)

MariaDB против MySQL

Оригинальная версия 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. Частота релизов

Политика Oracle – выпускать обновления безопасности для всех своих продуктов каждые три месяца. Но выход новой версии MySQL запланирован каждые два месяца. Это часто приводит к тому, что обновления продукта и обновления безопасности не синхронизируются.

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

MariaDB выпускает обновления программы и обновления безопасности синхронизировано, поэтому все ошибки успевают исправить. Все исправленные CVE задокументированы и любой пользователь может узнать что изменилось в новой версии.

3. Возможности и функциональность

В целом 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.

4. Поддержка движков хранения данных

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

• Aria;
• XtraDB – улучшенная версия InnoDB;
• FederatedX – улучшенная версия Federated;
• OQGRAPH;
• SphinxSE;
• IBMDB2I;
• TokuDB;
• Cassandra;
• CONNECT;
• SEQUENCE;
• Spider;
• ColumnStore;
• MySIAM.

Напомню, что оригинальная MySQL поддерживает по умолчанию только три типа таблиц – Aria, MySIAM и InnoDB. Это важный аспект в выборе MySQL или MariaDB.

5. Имя и нумерация версий

Эти отличия MariaDB от MySQL не столь важны, но, возможно, они будут кому-то интересными. Имя MySQL было дано в честь первой дочери одного из разработчиков – Майкл Монти, ее зовут My. Разработку MariaDB продолжил тот же человек и на этот раз программа была названа в честь его младшей дочери – Марии.

Что касается версий, то изначально, до версии 5.6 версии MariaDB нумеровались синхронно до версий MySQL, на которых они были основаны. Но когда накопилось достаточно изменений и за основу стал браться код MariaDB номера версий было принято поменять на 10. С того момента нумерация MariaDB выполняется только так.

Выводы

В этой статье мы сделали сравнение MySQL vs MariaDB. По большинству параметров MariaDB намного лучше, чем MySQL, поэтому не зря большинство дистрибутивов Linux теперь используют ее по умолчанию в своих репозиториях. Оригинальная версия может понадобиться только в очень редких случаях.

Следует ли переходить?

Очевидно, что новые функции MariaDB не такие уж и волшебные – вам, возможно, потребуется доступ к некоторым данным Cassandra, но сомневаюсь, что для этого вы воспользуетесь MySQL. То же самое относится и к другим движкам на данной платформе. Производительность MariaDB немного выше на многоядерных компьютерах, однако, полагаю, что под это можно настроить и MySQL.

Во-первых, продумайте всевозможные риски (руководители высшего звена любят слушать про риск и пользу). Если вы перейдёте на MariaDB, возможно, вы начнёте пользоваться функциями, доступными только для MariaDB (что пока что маловероятно), а затем окажется, что вернуться назад к MySQL, не приложив усилий, не получится. Но осмелюсь предположить, что это не такой уж и риск, если учесть некоторые более масштабные проблемы.

Поразмышляйте над всеми вопросами насчёт Oracle и её планами по лицензированию MySQL. MySQL с открытыми исходниками идёт вразрез с патентованными и очень конкурентными программами. Только это является поводом для размышлений – будет ли Oracle что-либо предпринимать, чтобы как-то помешать разработке MySQL? Некоторые утверждают, что это уже происходит.

А что насчёт совместимости MySQL и MariaDB? Команда MariaDB усердно работает над тем, чтобы сделать базу данных полностью совместимой с MySQL, и они продолжают устранять ошибки в исходнике. Однако новые функции (а также схема нумерации версий) предполагают, что, несмотря на все усилия, обе платформы будут сильно различаться.

Если Oracle добавит к MySQL некоторые новые функции, которые не поддерживаются MariaDB, то очевидно, что они не будут доступными для вас. А если вы будете пользоваться функциями, отсутствующими в MySQL, вы не сможете обратно на него перейти, учитывая, что у вас были причины перейти на другую платформу. MariaDB подаёт все признаки того, что она довольно долгое время будет в ходу, что нельзя сказать о MySQL. Другими словами, даже если новые функции MariaDB могут и не быть полезными для всех, на мой взгляд, существует более чем достаточно причин, чтобы отказаться от MySQL и полностью перейти на MariaDB.

Любое использование материалов сайта возможно только с разрешения автора и с обязательным указанием источника.

MySQL, MariaDB — в чем разница?

Информации пока по этому поводу немного. Например Компания RedHat официально объявила о замене пакета MySQL на MariaDB в качестве пакета стандартной СУБД для веб-разработчиков:

А годом ранее, использовать MariaDB начал community проект Fedora. Пока использовали в качестве теста, оставляя приоритетным пакет mysql, однако в 19й версии главным будет именно пакет mariadb, а mysql будет выкладываться под названием community-mysql:

MariaDB в Википедии

Фонд Викимедия пару месяцев назад так же заявил о переходе на использование Марии в качестве бд. Пока для английской и немецкой версии википедии и ряда связанных проектов:

MariaDB в Мозилле

Три недели назад обновляли сайт поддержки мозиллы с mysql 5.1 на mariadb 5.5, правда не без косяков, но они были связаны с переходом с 5.1 на 5.5.

MySQL, MariaDB — в чем разница?

Многие из вас наверное в курсе что пять лет назад компанию MySQL купила компания Sun, а два года назад компанию Sun купила компания Oracle. Они как-то плохо её развивали, и делали всякие enterprise версии. Главный разработчик Michael Widenius (Monty) создатель MySQL, движка MyISAM и кучи всего — взял всех главных разработчиков и свалил в опенсорс. И они начали переписывать код так чтобы всё было в несколько раз быстрее и оптимизированней. Поэтому-то Фёдора с 17го релиза включала mariadb как альтернативную бд. В 19й версии они совсем заменят миску на марию. Мы с коллегами поглядели тесты, прониклись и решили попробовать уже сейчас.

Структура самих баз полностью идентична (читай совместима) — разные только сами программы. Подробнее можете почитать на офицальном сайте —https://mariadb.org. Мария должна (как и грядущая mysql 5.6) совсем не снижать производительности при большой нагрузке.

Для Fedora (и в будущем redhat и centos) система установки через yum очень простая — просто останавливаете Apache и Mysql, удаляете миску (php_mysql тоже удаляется по зависимостям), и ставите марию (и снова php_mysql).

Для фёдоры она есть в официальном репозитории начиная с 17й версии: http://mirror.yandex.ru/fedora/linux/updates/17/i386/, есть также и «родные» сборки для неё
http://mirror.timeweb.ru/mariadb/mariadb-5.5.31/yum/fedora17-x86/rpms/
https://downloads.mariadb.org/mariadb/repositories/ — собственно у них для всего есть свои сборки.

Новшества

Совместимость и быстродействие

Интересные факты

Создатель этих СУБД (Monty) называл их так в честь своих детей. MySQL — он так назвал в честь дочери My, MariaDB — в честь соответственно Maria и ещё он сделал движок MaxDB назвав соответственно в честь сына. Компания Oracle название mysql оставило себе, так что проект пришлось переименовать. Вместо MyISAM (который тоже в честь My) — он сделал новый движок Aria — который вроде будет очень быстрый. Сначала назвал Maria — но потом подумал что будет много путанницы. В общем объявил конкурс на название и победило Aria

Вот уже пару недель как наш сервер использует MariaDB 5.5.31 в качестве основной СУБД. Да, да, и этот блог тоже =). (Кстати мы используем фёдору и центос на наших серверах). Полёт отличный. По грубым прикидкам скорость исполнения «медленных» запросов возрасла в 5-10 раз, быстрых запросов в 7-9 раз. Я уже предварительно договорилась с крупным хостинг-провайдером, чтобы они сообщили о результатах внедрения.

выбираем замену для популярной СУБД — «Хакер»

Содержание статьи

Что будет теперь, когда ненавистная и даже глубоко противная истинным сторонникам открытого софта компания 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-тренд

Ты наверняка знаешь о новомодном тренде 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, не нарушая при этом совместимости. Ты все еще сидишь на стареньком мускуле? Тогда мы идем к тебе!

 

Links

[2020] Все, что вам нужно знать

MySQL — одна из наиболее широко используемых баз данных в мире. Это бесплатно и с открытым исходным кодом. MySQL, разработанный на C / C ++, является одним из самых популярных вариантов баз данных.

База данных была создана шведской компанией MySQL AB в 1995 году. Позже MySQL AB была приобретена Sun Microsystems в 2008 году. Позже Sun Microsystems была приобретена Oracle в 2010 году. С тех пор MySQL поддерживается и управляется Oracle.

Во время приобретения Sun Microsystems компанией Oracle некоторые старшие инженеры, работавшие над разработкой MySQL, почувствовали конфликт интересов между MySQL и коммерческой базой данных Oracle — Oracle Database Server.В результате эти инженеры создали вилку базы кода MySQL и основали свою собственную организацию. Так родился MariaDB.

На сегодняшний день обе базы данных очень популярны и широко используются сообществом разработчиков. MySQL занимает 2-е место среди реляционных баз данных и 2-е место в целом (1-е место — база данных Oracle). Напротив, MariaDB немного отстает — 9-е место среди реляционных баз данных и 14-е место в целом.

MariaDB против MySQL

В этой записи блога мы попытаемся сравнить некоторые функции обеих этих баз данных, чтобы увидеть, какая из них лучше всего подходит для использования в 2020 году.

MariaDB и MySQL Сравнение производительности

MariaDB имеет несколько оптимизаций, направленных на повышение производительности по сравнению с MySQL. Фактически, это было именно то видение, когда MariaDB была основана Майклом Видениусом, первоначальным основателем как MySQL, так и MariaDB.

Просмотры базы данных

В качестве примера, есть огромная оптимизация производительности в отношении «представлений» базы данных. «Представления» по сути являются виртуальными таблицами базы данных, к которым можно обращаться как к обычным таблицам базы данных.В MySQL, когда вы запрашиваете представление, запрашиваются все таблицы, которые связаны с представлением, независимо от того, что для запроса могут не потребоваться некоторые из представлений. Это было оптимизировано в MariaDB, где запрашиваются только те таблицы, которые требуются для запроса.

ColumnStore

В качестве другого примера MariaDB обеспечивает еще одно мощное улучшение производительности в виде «ColumnStore», который представляет собой распределенную архитектуру данных, которая позволяет значительно масштабировать MariaDB.Он может линейно масштабироваться для хранения петабайт данных на различных серверах в кластере базы данных.

Лучшая производительность во флеш-хранилище

MariaDB также предоставляет механизм хранения MyRocks, который добавляет к нему базу данных RocksDB. RocksDB — это база данных, которая была разработана для повышения производительности во флэш-хранилищах за счет обеспечения более высокого уровня сжатия данных.

Кэш сегментированных ключей

MariaDB представляет еще одно улучшение производительности в виде кеширования сегментированных ключей.В типичном кэше различные потоки конкурируют за блокировку кэшированной записи. Эти блокировки называются мьютексами. Когда несколько потоков конкурируют за мьютекс, только один из них может получить его, в то время как другим приходится ждать освобождения блокировки перед выполнением операции. Это приводит к задержкам выполнения в этих потоках, снижая производительность базы данных. В случае Segmented Key Cache потоку не нужно блокировать всю страницу, но он может блокировать только тот сегмент, к которому страница принадлежит.Это помогает нескольким потокам работать параллельно, тем самым увеличивая параллелизм в приложении, что приводит к повышению производительности базы данных.

Виртуальные столбцы

Интересная функция, которую поддерживает MariaDB, — это виртуальные столбцы. Эти столбцы могут выполнять вычисления на уровне базы данных. Это чрезвычайно полезно, когда многие приложения обращаются к одному и тому же столбцу, и поэтому нет необходимости записывать вычисления в каждом приложении — база данных может сделать это за вас.Эта функция недоступна в MySQL.

Параллельное выполнение запросов

Одна из последних версий MariaDB — 10.0 позволяет параллельно выполнять несколько запросов. Идея состоит в том, что некоторые запросы от Мастера могут быть реплицированы на ведомом и, следовательно, могут выполняться параллельно. Этот параллелизм в выполнении запросов, безусловно, дает MariaDB преимущество перед MySQL.

Объединение потоков

MariaDB также представляет новую концепцию под названием «пул потоков».Раньше, когда требовалось несколько подключений к базе данных, для каждого подключения открывался поток, что приводило к архитектуре на основе «один поток на подключение». При использовании «пула потоков» будет существовать пул открытых потоков, которые новое соединение может выбрать и запросить базу данных. Таким образом, нет необходимости открывать новый поток для каждого нового запроса на соединение, что приводит к более быстрым результатам запроса. Эта функция доступна в версии MySQL Enterprise, но, к сожалению, недоступна в версии Community.

Двигатели для хранения

MariaDB предоставляет несколько мощных механизмов хранения «из коробки», которых нет в MySQL. Например, XtraDB, Aria и т. Д. Чтобы настроить эти механизмы хранения для MySQL, вам необходимо установить их вручную, что может быть не самым удобным.

Совместимость

Команда

MariaDB заботится о том, чтобы MariaDB могла легко заменить MySQL в существующих приложениях. Фактически, для каждой версии MySQL они выпускают один и тот же номер версии MariaDB, чтобы указать, что MariaDB в целом совместима с соответствующей версией MySQL.Это открывает возможность беспрепятственного перехода на MariaDB без каких-либо изменений в кодовой базе приложения.

Открытый исходный код и проприетарная база данных

MySQL — это большой проект, которым управляет одна из крупнейших организаций в мире — Oracle. В этом есть свои плюсы и минусы. Один из самых больших недостатков заключается в том, что выпуск новых функций в крупных организациях занимает много времени. С другой стороны, MariaDB имеет полностью открытый исходный код, и они довольно быстро принимают участие со стороны и выпускают новые функции и улучшения.Это еще один момент, который необходимо учитывать при выборе между MySQL и MariaDB.

Заключение

MariaDB, несомненно, довольно мощный и предоставляет множество функций, которые чрезвычайно полезны и не поддерживаются в MySQL. Такие функции действительно делают MariaDB выгодным выбором для использования в качестве основной серверной базы данных. Вообще говоря, организациям, которые уже приобрели лицензии для Oracle, не нужно вкладывать средства в MariaDB. Однако для тех, кто начинает все заново и хочет решить, какую базу данных использовать, несомненно, MariaDB — лучший выбор.

Какую базу данных вы выберете, на Hackr.io есть руководства по программированию, рекомендованные сообществом для обоих:

Еще читают:

.

MariaDB против MySQL: противостояние

.

Обновление до MariaDB с MySQL 5.0 или более ранней версии

Если вы обновляетесь до MariaDB 5.1 с MySQL 5.1, вам не нужно ничего делать с вашими данными или клиентами MySQL. Вещи должны «просто работать».

При обновлении между различными основными версиями MariaDB или MySQL вам необходимо
запустите программу mysql_upgrade для преобразования данных, несовместимых между версиями. Это также обновит ваши таблицы привилегий в базе данных mysql до последнего формата.

Почти во всех случаях mysql_upgrade должен иметь возможность преобразовывать ваши таблицы без необходимости выгрузки и восстановления ваших данных.

После установки MariaDB просто выполните:

 mysql_upgrade --verbose
 

Если вы хотите работать с определенным портом TCP / IP, выполните:

 mysql_upgrade --host = 127.0.0.1 --port = 3308 --protocol = TCP
 

Если вы хотите подключиться к розетке, сделайте:

 mysql_upgrade --socket = 127.0.0.1 --protocol = сокет
 

Чтобы увидеть другие параметры, используйте —help.

«mysql_upgrade» считывает разделы my.cnf [mysql_upgrade] и [client] для значений по умолчанию.

Существует множество причин, по которым таблицы необходимо преобразовать; они могут быть любыми из следующих:

• Параметры сортировки (порядок сортировки) для столбца индекса изменились
• Тип поля изменил формат хранения
• Двигатель имеет новый формат хранения
  • АРХИВ изменил формат хранения с 5.0 и 5.1
• Изменился формат хранения имен таблиц
  • В MySQL 5.1 имена таблиц закодированы так, что имена файлов идентичны на всех компьютерах. Старые имена таблиц, которые содержат запрещенные символы имени файла, будут отображаться с префиксом # mysql50 # в SHOW TABLES , пока вы их не конвертируете.

Если не преобразовать таблицы, может произойти одно из следующих событий:

• Вы будете получать предупреждения в журнале ошибок каждый раз, когда обращаетесь к таблице с недопустимым (старым) именем файла.
• При поиске по ключевым значениям вы не можете найти все строки
• Вы получите сообщение об ошибке «ОШИБКА 1459 (HY000): требуется обновление таблицы» при доступе к таблице.
• Возможны сбои

«mysql_upgrade» работает, вызывая mysqlcheck с различными параметрами и выполняя сценарий «mysql_fix_privileges». Если у вас возникли проблемы с «mysql_upgrade», вы можете запустить эти команды отдельно, чтобы получить больше информации о том, что происходит.

Большинство вещей в MySQL 5.1 раздел руководства также относится к MariaDB.

Между mysql_upgrade в MariaDB и MySQL (начиная с MariaDB 5.1.50) существуют следующие различия:

• MariaDB правильно преобразует длинные имена таблиц.
• MariaDB преобразует таблицы InnoDB (нет необходимости делать дамп / восстановление или ALTER TABLE ).
• MariaDB преобразует старые архивные таблицы в новый формат 5.1 (примечание: новая функция находится в стадии тестирования).
• «mysql_upgrade —verbose» запустит «mysqlcheck —verbose», чтобы вы получили больше информации о том, что происходит.

.