У MySQL существует несколько альтернатив, на которые вы в любой момент можете переключиться.  Лучшие из них это MariaDB и Percona. MariaDB является ответвлением MySQL, которое развивается при участии всего сообщества по лицензии GNU GPL. Создателями решения являются оригинальные разработчики  MySQL. Основные цели MariaDB включают в себя поддержание высокой совместимости с MySQL, обеспечение возможности “drop-in” замены с библиотекой двоичной эквивалентности и сопоставление с командами и API MySQL. В свою очередь Percona Server является еще одной бесплатной альтернативой MySQL. Решение обладает высокой масштабируемостью, улучшенной производительностью, нехарактерными для базового движка особенностями и всеми необходимыми инструментами. Кроме того, Percona полагается на алгоритмы самонастройки и обладает поддержкой передового мощного железа. Далее мы расскажем о том, когда стоит переходить на альтернативы MySQL, такие как MariaDB и Percona.

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

Время загрузки страницы

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

• Правильно настройте размер кэша для MySQL. К сожалению, универсального решения тут нет, так как каждый проект обладает уникальными особенностями, под которые придется подстраиваться.

• Не забудьте минимизировать задержку сети.  Для фрейма на 64 байта необходимо выставить следующие значение: 4.096 µs для 1 Gbps, 5.12 µs для 100 Mbps, 51.2 µs для 10 Mbps. При переходе от 100 Mbps к 1 Gbps результат можно улучшить на 20%.

• Кроме того, можно пошаманить с мощностью сети. Увеличьте этот параметр как минимум до 100 Mb/s или используйте локальный DB сервер.

• Используйте SOLR. Внешние движки зачастую работают быстрее:  ненастроенный SOLR справляется с многослойной навигацией быстрее, чем это делает MySQL.

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

• Поработайте с логами MySQL. Проверьте все медленные запросы и добавьте индексы там, где это необходимо.

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

Не тратьте время на

• Смену движка, так как MariaDB и Percona включают в себя InnoDB, который работает точно так же, как и стоковое решение MySQL.

• Запуск MySQL слейва (исключение составляют те случаи, когда слейв находится ближе и работает на более мощном железе).

• Внешний DB сервер, только если вы не нуждаетесь в дополнительных ресурсах или нескольких серверах. В остальных случаях MySQL на локальной машине показывает более высокие результаты, так как все перегрузки и задержки, связанные с использованием сети, отсутствуют. Даже сеть на 100 Gb/s не может быть лучше.

Общая мощность

MySQL может быть проблемой. На определенном этапе стандартное решение имеет все шансы ограничить общую мощность Magento магазина. При наличии Varnish и FPC  правильными настройками, MySQL становится проблемой. Чтобы увеличить производительность Magento, вы можете выполнить следующие действия:

• Используйте альтернативный движок. Например, XtraDB. Он показывает более серьезные результаты при нагрузках.

• Обновляйте MySQL – новая версия всегда лучше работает.

• Установите PHP MySQL драйвер. В большинстве случаев он показывает более высокие результаты, чем родное решение MySQL.

• И не забудьте о поисковых движках. SOLR/Sphinx или любой другой аналогичный сервис позволит снять часть нагрузки с Magento сайта.

• Поменяйте движок многослойной навигации: SOLR всегда быстрее, чем MySQL.

• Установите MySQL слейв. Это позволит увеличить мощность, но никак не отразится на максимальном количестве обрабатываемых в час запросов.

Не тратьте время на

• Master/Master. Не используйте Master/Master, так как проблем будет гораздо больше, чем выгоды.

Read vs Write

Read масштабируемость может выполняться бесконечно без добавления новых слейвов. Соотношение Reads к Writes в Magento составляет всего 0,1%, так что не питайте никаких надежд по поводу writes.

Железо

Все изменения в софте могут оказаться бесполезными, если вы используете плохое железо. Следует убедиться, что вы не используете что-то из упомянутого далее:

• Перенасыщенные сетевые связи

• Низкокачественные переключатели с ограниченным буфером

• Удаленные сервера и бедные QoS/CoS сети

• Ограниченное количество ОЗУ и ОЗУ с низкой пропускной способностью

• Программный RAID контроллер

• Некачественные IOP HDD подсистемы

• Процессоры с низкой тактовой частотой

• Практически все типы виртуального железа

На данный момент существуют серверы, которые включают в себя до 160 ядер и 2 TB оперативной памяти. Аналогичные же облачные решения значительно им уступают. Учитывая все это, стоит отметить, что в любом Magento проекте существует огромное количество возможностей для вертикальной масштабируемости, которыми стоит воспользоваться, прежде чем переходить к горизонтальной масштабируемости.

Постоянное увеличение производительности

Проблемы всегда будут появляться – с этим необходимо смириться. Любые улучшения приводят к появлению новых трудностей, вот несколько примеров для обычного Magento магазина:

• Включая кэш, добавляя кэш для бэкенда, фронтенда или full page кэш, используя альтернативные движки, вы обязательно столкнетесь с проблемами, связанными с PHP.

• Для фронтенд кэша уровня серверов и дополнительных серверов приложений сложности возникают с MySQL.

• Добавляя MySQL слейв, вы сталкиваетесь с трудностями, связанными с работой фронтенд кэша.

• Для дополнительных серверов приложений проблему составляет SOLR/Sphinx.

Вносите только продуманные изменения

Не стоит добавлять MySQL слейв только по той причине, что кто-то говорит об увеличении производительности для этого решения. Любое изменение должно быть обоснованно в соответствии со всеми особенностями каждого конкретного Magento проекта. В противном случае вы рискуете обзавестись лишней головной болью.

Примеры

300 заказов в час

Чтобы обработать 300 заказов в час, вполне достаточно следующего железа:

1 сервер

• 2x Intel E5-4620

• 64GB HDD: 4x 80k IOP/s SSDs

• Hardware RAID 10

• Magento EE

• MageStack

Средние нагрузки не превысили 3.00. При таких условия необходимость в локальных MySQL слейвах возникает только при пиковых нагрузках.

180 заказов в час

• 2x Intel E5-4620

• 64GB HDD: 4x 80k IOP/s SSDs

• Hardware RAID 10

• Magento CE

• MageStack

Firewall Пакеты

Varnish Трафик

Nginx Трафик

Загрузка MySQL

Загрузка процессора CPU

Распределение загрузки

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

Заключение

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

Другие преимущества альтернативных MySQL движков

Не забывайте, что производительность является не единственным козырем альтернативных движков. Они также обладают следующими преимуществами:

• Более полный набор инструментов(например, Percona включает в себя pt-query-digest и xtrabackup)

• Более высокая частота обновлений

• Хорошая поддержка

• Уникальные особенности: Percona обеспечивает теплые рестарт кэша с сохранением InnoDB бассейна