И сейчас встал выбор СУБД для хранения основных данных. Начинал разработку на MySQL, но сейчас не уверен в выборе. Переезд на другую СУБД на данном этапе для меня не составит проблем (использую PDO). далек от ясного понимания что такое «высокие нагрузки» для СУБД. Просто по моим расчетам примерно через год база будет весьма увесистой (см. ниже)

Основной выбор стоит между MySQL, PostgreSQL, MariaDB. Также, возможен, но не приветствуется вариант Microsoft SQL Server на Windows Azure

Ситуация такова:

1. Сложных запросов к базе нет. Максимум JOIN из двух таблиц
2. Бо льшая часть запросов - чтение
3. Есть одна самая важная и «главная» таблица (структура таблицы ниже под спойлером). Таблица будет расти примерно на 10-30 тысяч записей в сутки. Запись данных в эту таблицу - самое главное!
4. Бо льшая часть запросов на чтение будет как раз к «главной» таблице. По этой таблице будет осуществляться поиск по любому из полей (в крайне редких случаях ~0.5% - по нескольким сразу). Поиск должен осуществляться быстро (не смотря на пункт №3)
5. К «главной» таблице скорее всего будут добавлены индексы к каждому из полей сразу для двух полей (ownerID и Имя поля т.к. ownerID будет указан во всех запросах). Быстрый поиск будет нужен по любому из полей, но это не столь приоритетная задача. (Или лучше использовать Sphinx?)
6. Львиная доля запросов (~80%) на чтение к «главной» таблице - простые select"ы по индексам from и personalID с limit = 20. Остальные запросы по любым другим полям по индексам (которых пока нет) ownerID и Имя поля, также с limit = 20
7. Изменения данных в записях «главной» таблицы будут происходить крайне редко. Никакие записи из таблицы удаляться не будут.
8. Поддержка транзакций и внешних ключей не обязательна
9. Нужна возможность репликации данных типа master-slave
10. Возможность шардинга на уровне СУБД приветствуется
11. Крайне важна надежность БД (т.е. такой крах, как у MyISAM с ручным восстановлением сразу отпадает)
12. К «главной» таблице могут добавляться новые поля. Это конечно крайне редкое явление и далеко не самое важное требование, но добавление нового столбца к таблице размером с десяток ГБ для MySQL весьма длительный процесс, а выносить новые поля в отдельную таблицу очень не хочется
13. Всё это по-началу будет крутиться на таком вот выделенном сервере
14. Другие таблицы будут расти медленно, и обращения к ним будут достаточно редкими, за них я не переживаю. Часто обновляемые данные у меня крутятся в redis"e

Структура «главной» таблицы CREATE TABLE IF NOT EXISTS `clients` (`id` bigint(11) NOT NULL AUTO_INCREMENT, `personalID` int(11) NOT NULL, `ownerID` int(11) NOT NULL, `fromID` int(11) NOT NULL DEFAULT "4", `fromDomain` varchar(255) NOT NULL, `datetime` datetime NOT NULL, `status` int(11) NOT NULL DEFAULT "0", `paid` tinyint(1) NOT NULL DEFAULT "0", `paymentType` tinyint(4) NOT NULL DEFAULT "1", `wmSum` float NOT NULL DEFAULT "0", `wmCommission` float NOT NULL DEFAULT "20", `sysNumber` varchar(14) NOT NULL, `sysNumberLastUpdate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `sysNumberStatus` varchar(250) NOT NULL, `timezone` float NOT NULL, `comment` varchar(500) NOT NULL, `countryID` int(11) NOT NULL, `postIndex` varchar(6) NOT NULL, `region` varchar(500) NOT NULL, `city` varchar(500) NOT NULL, `address` varchar(500) NOT NULL, `fio` varchar(500) NOT NULL, `phone` varchar(15) NOT NULL, `email` varchar(255) NOT NULL, `price` float NOT NULL, `quantity` int(11) NOT NULL DEFAULT "1", `label` varchar(30) NOT NULL, `tag` int(11) NOT NULL, `ip` varchar(15) NOT NULL, `referer` varchar(200) NOT NULL, PRIMARY KEY (`id`), KEY `from` (`ownerID`,`fromID`), KEY `paid` (`paid`), KEY `status` (`status`), KEY `label` (`label`), KEY `sysNumberLastUpdate` (`sysNumberLastUpdate`), KEY `personalID` (`ownerID`,`personalID`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

P.S. Желающих отправить меня гуглить прошу даже не отвечать. Найти информацию по сравнению актуальных версий разных СУБД мне не удалось, а изучать возможности, плюсы и минусы PostgreSQL, Microsoft SQL Server и MariaDB для человека, который с ними не работал весьма долгая задача. Да и в MySQL я далеко не эксперт, и подобный крупный проект для меня дело новое, да и возможности MySQL от версии к версии отличаются. Единственное, что я точно знаю, так это то, что таблицы типа MyISAM в MySQL мне точно не подойдут

• Вопрос задан более трёх лет назад
• 39797 просмотров

MySQL стал собственностью Oracle, есть ли альтернативы и как быстро движение вперед?.. Вроде как обобщающего обзорчика «who is who?» еще не было. Итак, обзорчик для тех кто «не в теме»

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

Майкл Видениус (Michael Widenius), основатель MySQL и основатель компании MySQL AB (которую и поглотила Sun, которую и поглотила Oracle)
Петр Зайцев - эксперт по производительности MySQL, бывший тимлидер группы High Perfomance в MySQL Inc, ведущий блога MySQLPerformanceBlog.com

Итак, какие существуют альтернативы?

Percona server - это сборка MySQL (от Петра Зайцева и ко) с включенным по умолчанию XtraDB storage engine. Отличается от MySQL+InnoDB plugin лучшей производительностью/масштабируемостью, особенно на современных многоядерных серверах. Также улучшена функциональность - больше всякой полезной для оптимизации статистики и пр. Собирается в вариантах базирующихся на MySQL 5.0 и 5.1. Полностью совместим с таблицами innodb, то есть можно переходить от innodb к xtradb и обратно без проблем (если не использовать некоторые специфичные для xtradb функции, типа меньшего размера страницы).

Хранилище XtraDB основано на коде InnoDB-plugin, полностью совместимо с ним, но отличающийся заметно более высокой производительностью, благодаря интеграции патчей от компаний Google и Percona. В частности, в XtraDB улучшен механизм работы с памятью, улучшена работа подсистемы ввода/вывода InnoDB, добавлена поддержка нескольких потоков чтения и записи, поддержка управления пропускной способностью, реализация упреждающей выборкой данных (read-ahead), адаптивная установка контрольных точек (adaptive checkpointing), расширены возможности по масштабированию для больших проектов, система организации блокировок адаптирована для работы на системах с большим числом CPU, добавлены дополнительные возможности для накопления и анализа статистик

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

• Новые хранилища данных:
  • Aria (ранее Maria) - основанное на MyISAM высоконадежное хранилище, отличающиеся повышенной устойчивостью и сохранению целостности данных после краха, при полной совместимости с MyISAM
  • OQGRAPH (хранилище для организации сложных графов)
  • Sphinx - хранилище для построения поисковых движков
  • PrimeBase XT - описание на русском
  • В качестве замены InnoDB используется движок XtraDB
  • FederatedX - позволяет организовать обращение к удаленным таблицам как к локальным
• Патчи MyISAM движка - Сегментированный кэш (при высоких нагрузках дает существенный прирост)
• Ликвидация таблиц - новый вид оптимизации запросов с использованием JOIN
• Пул потоков - теперь на одно соединение можно открыть больше одного потока
• Улучшены

От автора: система управления базами данных стала неотъемлемой частью разработки динамического веб-продукта. С ее помощью можно систематизировать весь массив необходимых файлов. Все это нужно для быстрого доступа и оптимизации работы приложения или сайта. Но чтобы полностью освоить все, пусть даже самые популярные, потребуются десятилетия. Следует определится, какую вы будете использовать, изучать, и прокачивать свой скилл. Самое популярное сравнение – 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 была разработана фино-шведской компанией 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 теперь используют ее по умолчанию в своих репозиториях. Оригинальная версия может понадобиться только в очень редких случаях.

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

Что такое MariaDB?

MariaDB - это альтернативная MySQL СУБД, которую разрабатывает автор MySQL Michael "Monty" Widenius. Основная цель проекта MariaDB - создание полностью бинарно совместимой с оригинальной MySQL версии СУБД, которая при этом будет иметь значительное количество улучшений в коде, влияющих на производительность. MariaDB разрабатывается как drop-in замена для MySQL, полностью имитируя поведение MySQL.

Почему вообще Monty решил сделать клон своего же детища? Дело в том, что права на MySQL принадлежат компании MySQL AB, которую сначала купили Sun Microsystems, а затем уже Sun продались корпорации Oracle. В итоге Monty решил уйти из Oracle и сделать, в некотором смысле, MySQL "на стероидах".

MariaDB: что в ней есть нового?

MariaDB версий 5.1, 5.2 и 5.3 (beta) базируется на коде MySQL 5.1, но с рядом нововведений и улучшений.

Во-первых, это ряд новых движков (database engine) для хранения данных. А именно: Aria - альтернатива таблицам MyISAM, более быстрая и устойчивая к сбоям. Таблицы Aria используются в MariaDB для внутренних нужд, в частности все temporary tables работают именно на движке Aria, за счет чего в ряде случаев получилось добиться значительно большей производительности на сложных запросах. Кроме того, таблицы InnoDB заменены на XtraDB (альтернатива InnoDB от компании Percona), так же более быстрые, чем оригинал, и более устойчиывые к сбоям.

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

Так же в MariaDB появился новый способ доступа к данным InnoDB - HandlerSocket. HandlerSocket в каком-то смысле является альтернативой memcached. Через интерфейс HandlerSocket с данными в таблицах InnoDB (XtraDB) можно работать как с набором данных "ключ-значение", где в качестве ключа выступает любой из индексов, созданных по любой из InnoDB-таблиц. По скорости работы HandlerSocket практически не уступает memcached и некоторые источники даже сообщают, что им удалось добиться большей, чем с memcached, производительности.

Сравнительные тесты

Для того, чтобы понять, стоит ли овчинка выделки и действительно ли проделанные в 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 следующим образом:

Mysqlslap --auto-generate-sql --concurrency=$i --number-of-queries=$(($i*500)) --iterations=3

то есть мы в цикле меняем переменную $i от 10 до 200, эмулируя при этом одновременную работу от 10 до 200 клиентов, каждый из которых делает по 500 запросов к базе данных. Далее мы замеряем общее время выполнения тестов. Тесты проводились на MariaDB версии 5.1 в сравнении с MySQL тоже версии 5.1

Таблицы MyISAM

Ниже приведены графики замеров производительности MySQL (верхний график) и MariaDB (нижний) на таблицах MyISAM. По оси X изображено количество одновременно работающих клиентов, по Y - время в секундах, затраченное на тест.

Как интерпретировать результаты: чем ниже точка на графике, тем быстрее отработал тест. Судя по графику, уже начиная с 60 одновременно работающих клиентов, MariaDB отработала тесты почти в 1,5 раза быстрее, чем MySQL.

Таблицы InnoDB

Здесь ситуация аналогичная: MariaDB победила, но только перевес здесь гораздо более значительный: производительность InnoDB в MySQL в разы хуже, чем производительность XtraDB в MariaDB.

Следует так же отметить, что данный тест замерял производительность работы только с одной таблицей, поэтому роста производительности на JOIN"ах, и особенно на запросах, выполнение которых делается при помощи создания временных таблиц, на этих графиках не видно. Реально при переходе на MariaDB даже для таблиц MyISAM производительность БД может вырасти в несколько раз.

Обращаем ваше внимание, что версия 5.1 у MariaDB, на которой проводились приведенные тесты, - это первоначальная версия, содержащая минимальный набор улучшений. В реальности мы используем на серверах MariaDB 5.2, а со временем планируем перейти на MariaDB 5.3, где улучшений и оптимизаций еще больше.