0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

Время для СУБД: MariaDB vs проверенная временем MySQL

Дата публикации: 2018-11-07

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

Тест производительности MySQL: MySQL 5.7 против MySQL 8.0

Главное меню » Базы данных » База данных MySQL » Тест производительности MySQL: MySQL 5.7 против MySQL 8.0

Со всеми этими классными функциями, улучшениями, улучшениями, которые предлагает MySQL 8.0, наша команда заинтересовалась, чтобы определить, насколько хорошо работает текущая версия MySQL 8.0, особенно учитывая, что наша поддержка версий MySQL 8.0.x в ClusterControl находится в процессе (так что следите за обновлениями). на этом. В этом посте не будут обсуждаться возможности MySQL 8.0, но мы намерены сравнить его производительность с MySQL 5.7 и посмотреть, как она улучшилась.

Настройка сервера и среды

Для этого теста мы намерены использовать минимальную настройку для производства с использованием следующей среды AWS EC2:

  • Тип экземпляра: t2.xlarge instance
  • Хранилище: gp2 (SSD-хранилище с минимальной 100 и максимальной 16000 IOPS)
  • vCPUS: 4
  • Память: 16 ГБ
  • MySQL 5.7 версия: MySQL Community Server (GPL) 5.7.24 Версия
  • MySQL 8.0: MySQL Community Server – GPL 8.0.14

Есть несколько переменных, которые мы установили для этого теста, а именно:

  • innodb_max_dirty_pages_pct = 90 ## Это значение по умолчанию в MySQL 8.0.
  • innodb_max_dirty_pages_pct_lwm = 10 ## Это значение по умолчанию в MySQL 8.0
  • innodb_flush_neighbors = 0
  • innodb_buffer_pool_instances = 8
  • innodb_buffer_pool_size = 8GiB

Остальные переменные, устанавливаемые здесь для обеих версий (MySQL 5.7 и MySQL 8.0), уже настроены ClusterControl для своего шаблона my.cnf.

Кроме того, пользователь, которого мы здесь использовали, не соответствует новой аутентификации MySQL 8.0, которая использует caching_sha2_password . Вместо этого обе версии сервера используют mysql_native_password , а переменная innodb_dedicated_server имеет значение OFF (по умолчанию), что является новой функцией MySQL 8.0.

Чтобы упростить жизнь, мы настроили узел версии MySQL 5.7 Community с ClusterControl с отдельного узла, затем удалили узел в кластере и выключили узел ClusterControl, чтобы сделать узел MySQL 5.7 бездействующим (без трафика мониторинга). Технически, оба узла MySQL 5.7 и MySQL 8.0 неактивны, и через них никакие активные соединения не проходят, так что это по сути чистый тест бенчмаркинга.

Читать еще:  Программа для восстановления удаленных фотографий — ФотоДОКТОР!

Используемые команды и сценарии

Для этой задачи sysbench используется для тестирования и моделирования нагрузки для двух сред. Вот следующие команды или сценарий, используемые в этом тесте:

sb-prepare.sh

sb-run.sh

Таким образом, скрипт просто подготавливает схему sbtest и заполняет таблицы и записи. Затем он выполняет чтение/запись нагрузочных тестов, используя скрипт /usr/share/sysbench/oltp_read_write.lua. Сценарий сбрасывает глобальное состояние и переменные MySQL, собирает данные об использовании процессора и анализирует операции строки InnoDB, обработанные сценарием innodb-ops-parser.py. Затем сценарии генерируют файлы * .csv на основе выгруженных журналов, которые были собраны во время теста, затем мы использовали электронную таблицу Excel, чтобы сгенерировать график из файлов * .csv.

Теперь перейдем к результатам графика!

Операции со строками в InnoDB

В основном здесь мы извлекли только строковые операции InnoDB, которые выполняют выбор (чтение), удаление, вставку и обновление. Когда количество потоков увеличивается, MySQL 8.0 значительно превосходит MySQL 5.7! Обе версии не имеют каких-либо конкретных изменений конфигурации, но только заметные переменные, которые мы установили. Таким образом, обе версии в значительной степени используют значения по умолчанию.

Интересно, что в отношении заявлений MySQL Server Team о производительности операций чтения и записи в новой версии графики указывают на значительное улучшение производительности, особенно на сервере с высокой нагрузкой. Представьте разницу между MySQL 5.7 и MySQL 8.0 для всех операций с строками InnoDB, есть большая разница, особенно когда количество потоков увеличивается. MySQL 8.0 показывает, что он может работать эффективно независимо от его рабочей нагрузки.

Обработанные транзакции

Как показано на графике выше, производительность MySQL 8.0 снова показывает огромную разницу во времени, необходимом для обработки транзакций. Чем ниже, тем лучше он работает, а значит быстрее обрабатывать транзакции. Обработанные транзакции (второй график) также показывают, что оба числа транзакций не отличаются друг от друга. Это означает, что обе версии выполняют почти одинаковое количество транзакций, но отличаются тем, насколько быстро они могут завершиться. Хотя мы могли бы сказать, что MySQL 5.7 все еще может справляться с большими нагрузками при более низкой нагрузке, но можно ожидать, что реалистичная нагрузка, особенно в производстве, будет выше, особенно в самый загруженный период.

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

MySQL 8.0 показывает большие улучшения, особенно для чтения. Он показывает свою эффективность в записи особенно для серверов с высокой рабочей нагрузкой. Некоторая отличная дополнительная поддержка, которая влияет на производительность MySQL для операций чтения в версии 8.0, – это возможность создавать индексы в порядке убывания (или прямого сканирования индекса). Предыдущие версии имели только сканирование по возрастанию или обратному индексу, и MySQL должен был выполнять сортировку файлов, если требовался сортировка по убыванию (если нужна сортировка файлов, вы можете проверить значение max_length_for_sort_data ). Нисходящие индексы также позволяют оптимизатору использовать многостолбцовые индексы, когда наиболее эффективный порядок сканирования смешивает восходящий порядок для некоторых столбцов и нисходящий порядок для других. Смотрите здесь для более подробной информации.

Ресурсы процессора

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

Позвольте нам сначала объяснить, как мы используем ресурсы ЦП здесь во время бенчмаркинга. sysbench не включает в себя коллективную статистику для аппаратных ресурсов, использованных или используемых в процессе, когда вы сравниваете базу данных. Из-за этого мы создали флаг, создав файл, подключившись к целевому хосту через SSH, а затем собрав данные из команды top в Linux и проанализировав их во время сна на секунду, а затем собрали снова. После этого возьмите самое значительное увеличение использования ЦП для процесса mysqld, а затем удалите файл флага.

Итак, давайте снова поговорим о графике, кажется, что он показывает, что MySQL 8.0 потребляет много ресурсов процессора. Больше, чем MySQL 5.7. Однако, возможно, придется иметь дело с новыми переменными, добавленными в MySQL 8.0. Например, эти переменные могут повлиять на ваш сервер MySQL 8.0:

  • innodb_log_spin_cpu_abs_lwm = 80
  • innodb_log_spin_cpu_pct_hwm = 50
  • innodb_log_wait_for_flush_spin_hwm = 400
  • innodb_parallel_read_threads = 4

Переменные с их значениями оставлены значениями по умолчанию для этого теста. Первые три переменные обрабатывают ЦП для повторного ведения журнала, что в MySQL 8.0 было улучшением из-за перепроектирования того, как InnoDB записывает в журнал REDO. Переменная innodb_log_spin_cpu_pct_hwm имеет привязку к процессору, что означает, что она будет игнорировать другие ядра процессора, если mysqld прикреплен только к 4 ядрам, например. Для параллельных потоков чтения в MySQL 8.0 добавлена новая переменная, для которой вы можете настроить количество используемых потоков.

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

Заключение

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

Переходя к новым функциям MySQL 8.0, похоже, что он использует преимущества самых современных технологий не только в программном обеспечении (например, значительное улучшение для Memcached, удаленное управление для лучшей работы DevOps и т. д.), Но и также в оборудовании. Например, замена latin1 на UTF8MB4 в качестве кодировки символов по умолчанию. Это будет означать, что для этого потребуется больше дискового пространства, поскольку UTF8 требуется 2 байта для символов, не входящих в US-ASCII. Хотя в этом тесте не использовался новый метод аутентификации с caching_sha2_password , это не повлияет на производительность, если он использует шифрование. После аутентификации он сохраняется в кеше, что означает, что аутентификация выполняется только один раз. Поэтому, если вы используете одного пользователя для своего клиента, это не будет проблемой и будет более безопасным, чем предыдущие версии.

Поскольку MySQL использует самое современное аппаратное и программное обеспечение, он меняет свои переменные по умолчанию.

В целом, MySQL 8.0 эффективно доминирует над MySQL 5.7.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

MariaDB против MySQL

Существует довольно много причин для того, чтобы перейти на MariaDB. Давайте посмотрим, настолько ли они веские, чтобы убедить вас это сделать.

MariaDB — разновидность исходного кода MySQL, отделившегося сразу после того, как начали появляться сомнения о том, что Oracle будет делать с лицензированием MySQL (MySQL был приобретён компанией Sun, которая вскоре была сама куплена Oracle). Это довольно оправданные сомнения, о которых я поговорю немного позже. Кроме своей роли «упрощенной версии» MySQL, MariaBD также обладает несколькими новыми функциями, которые, по мнению некоторых, делают её лучше MySQL.

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

Читать еще:  NTLDR is missing. Как восстановить загрузочный сектор и загрузочную запись?

Команда разработчиков MariaDB, должно быть, знают об этом, так как они решили использовать новую схему нумерации. Самая новая версия MariDB (которая всё ещё является альфа-версией) — Maria 10.0, за которой следует младший номер устройства:

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

Так что за новые функции? Давайте рассмотрим парочку из них.


Движок Cassandra

Одной из уникальных функций MariaDB является её движок для соединения с серверной версией СУБД Cassandra. Сам движок является просто посредником, который соединяется с сервером Cassandra, запущенным отдельно. Cassandra — это NoSQL хранилище данных, которое изначально было создано для Facebook, а затем стало проектом Apache; хотя оно и может использоваться в кластерах без единой точки отказа, оно всё ещё не является совместимым с ACID. Вообще, если вы собираетесь использовать Cassandra в качестве движка, не ожидайте такой же скорости производительности, как у InnoDB или ExtraBD.

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

Так что эта функция может быть полезной, если вы. мм. дайте подумать. ну.

Если вы пишете программное приложение, которое требует доступа к данным в Cassandra, тогда вам, возможно, лучше использовать встроенный Cassandra API, а не MySQL. Полагаю, что если вы мучаетесь с интерфейсом командной строки MySQL и нужно взять кое-какие данные, то Cassandra может оказаться полезной — но если вы собираетесь воспользоваться этим, то не проще ли помучаться с интерфейсом командной строки Cassandra?

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


Движок OQGraph

Не буду слишком много о нём рассказывать, так как идея та же, что и в Cassandra: движок является просто интерфейсом вычислительного движка Open Query Graph (хранилища для организации сложных графов). Это может помочь в некоторых специализированных приложениях, хотя адаптация структур графов к SQL формату является на первый взгляд немного странной.

Одним важным улучшением, что делает MariaDB более мощной, является использование XtraDB в качестве ускоренного замещения InnoDB. Но XtraDB добавляет новые возможности масштабирования, в которых нуждаются современные приложения — и именно в этом заключается главное отличие. Oracle утверждает, что на данный момент MySQL масштабирует лучше, чем когда-либо раньше. Возможно, это так и есть, но она хороша так же, как и её движок. А если движок на практике не масштабирует так, как следует, то и MySQL не сможет сделать этого лучше.


Режим атомарной записи

Одной из главных причин, почему следует выбирать реляционную базу данных, а не обычную NoSQL, является то, что реляционная база полностью совместима с ACID. Проще говоря, если возникает какая-либо ошибка, никто не хочет, чтобы все данные исчезли. И хотя на компьютерах разработчиков ошибки — явление не частое, они всё ещё происходят во многих IT центрах. На данный момент, стандартный InnoDB/XtraDB движок для записи данных использует двойную буферизацию, чтобы гарантировать успешную запись данных в случае какого-либо сбоя. Как бы то ни было, при работе с высокоскоростными SSD устройствами (возьмём в качестве примера), двойной буфер может плохо сказаться на производительности, не давая вам возможности использовать всю скорость SSD. Какое решение? Вы можете выбрать один буфер и воспользоваться режимом атомарной записи (Atomic Writes). Попробуйте на свой страх и риск и, лучше не на производстве.

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


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

А сейчас я хочу обратить ваше внимание на сравнительные тесты, проведенные командой MariaDB, и добавить кое-какие комментарии. В этом блоге выдвинута интересная точка зрения: если потоков меньше 16, MySQL работает хорошо, а если их количество больше — хотя, конечно, производительность продолжает немного расти, но не так хорошо, как в других версиях, с которыми её сравнивали (включая MariaDB-5.5.28a и MariaDB-10.0.1; посмотрите график теста производительности в начале этой статьи). Это довольно часто встречающаяся проблема в параллельном программировании при попытке ориентации на несколько ядер и потоков внутри ядра. Если построенные алгоритмы верны, то вы будете ощущать преимущества по мере увеличения ядер. Проблема в том, что вам придётся использовать в своём параллельном программировании 2 метода: 1) многопотоковый на нескольких ядрах и 2) векторизацию. Эти методы являются двумя сторонами нынешнего многоядерного программирования, и ваш код должен корректно их использовать.

Одним из наиболее распространённых результатов неправильного кодирования является то, что вы будете наблюдать прирост производительности при работе с первыми 8 или 16 потоками, после чего никакого улучшения наблюдаться не будет. Если у вас возникла такая проблема, то скорее всего дело в алгоритмах. И это будет в случае или с гиперпотоками, или с аппаратными потоками. Это именно то, что мы наблюдаем в тестах MySQL. Для меня это означает наличие проблем с масштабированием в MySQL, и это повод задуматься. В том же тесте у MariaDB также наблюдались некоторые проблемы, т.к. производительность уменьшалась, но незначительно; я предполагаю, что это не касается параллельных алгоритмов.

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

Больше всего мне хотелось бы увидеть разновидность или MySQL, или MariaDB, скомпилированную специально для сопроцессора Intel Xeon Phi, где код разгружает 61-ядерный cопроцессор, а кто-то пытается раскрутить все 244 потока. К сожалению, у меня нет доступа к такой машине. Также, если вы хотите узнать больше о векторизации и параллельном кодировании, почитайте последнюю книгу сотрудников Intel Джеймса Джефферса (James Jeffers) и Джеймса Райндерса (James Reinders) «Высокопроизводительное программирование для сопроцессора Intel Xeon Phi».

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector