По следам HighLoad++ 2012 (MySQL плагины, оптимизация при помощи YSlow, CUBRID)

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

Вряд ли кто-то активно использует кастомные плагины для MySQL, а ведь оказывается их огромное количество. И с их помощью можно достаточно серьезно протюнить базу: добавить дополнительные методы аутентификации, добавить дополнительную функциональность для аудита — вести лог подключений к БД или же в специальный лог сбрасывать SQL-ошибки (а-ля «таблица не найдена», синтаксические ошибки и т.п). Так же отдельный интерес представляют демоны-плагины. При помощи них, например, можно осуществлять heartbeat (проверять состояние сервера — не повис ли и все такое). Так же к числу плагинов-демонов относится широко известный Handler Socket (предоставляющий новый протокол доступа к БД). Помимо этого при помощи плагинов к функциональности можно добалвять дополнительные парсеры текста и расширять язык запросов (к примеру, mnoGoSearch — MySQL fulltext parser plugin). Ну и естественно, при помощи плагинов можно подключать различные дополнительные движки, обеспечивающие хранение данных определенных форматов или же высокую доступность и т.п.

Вообщем вот как-то так… Подробнее с плагинами можно ознакомиться в официальной документации. Да, кстати, а пиар MariaDB таки был (!), но в другом докладе, в другое время и в другом зале.

От докладчика из Twitter-а, если честно, я ожидал чего-то большего. По факту в докладе рассказывалось про утилиту YSlow от компании Yahoo. Наверняка после этой фразы 99% людей, кто читает эту статью, вспомнят про старый добрый плагин для Firebug-а, проверяющий сайт на соответствие неким правилам хорошего тона в web-разработке, в духе: «используйте gzip-ование отдаваемого контента», «собирайте JS и CSS в один файл», «добавьте заголовки для кэширования… оп! а вот тут у вас картиночка отдается незакэшированная!» . Кстати говоря, у Google есть аналогичный инструмент и называется он Google Page Speed, и тоже поставляется как плагин для Firefox-а (ну и как плагин для Chrome, естественно).

В докладе же рассматривалось более широкое применение YSlow. Так есть специальное решение в виде консольной утилиты, которая, как я понял, запускается с помощью NodeJS, на вход получает HAR-файл/файлы и на выход отдает информацию о производительности ресурса. При помощи разнообразных опций можно моделировать формат и детализацию выводимой информации. По мнению авторов, особенно круто эту утилиту использовать вкупе с Jenkins-ом и continuous integration.

Далее речь зашла про интеграцию YSlow с PhantomJS. PhantomJS — это консольный эмулятор WebKit-браузера без графического интерфейса, позволяющий при помощи управления на JavaScript-е загружать страницу прямо из консоли и производить с ней различные манипуляции (тестировать наступление различных событий, к примеру). Применительно к YSlow, в отличии от предварительно сгенерированных HAR-файлов, PhantomJS позволяет анализировать живые работающие сайты. Для случая работы из-под PhantomJS имеется специально подготовленный скрипт yslow.js, консольный запуск которого выглядит примерно как-то так:

$ phantomjs yslow.js --info basic --format plain http://www.test.com

В этом случае предоставляется ряд дополнительных форматов вывода для автоматизированного тестирования — TAP и JUnit (последний видимо для интеграции с Jenkins-ом). Так же имеется возможность задавать различные заголовки (User-Agent, Cookie) и указать размеры «отображаемой» страницы (как если бы страница загружалась из окна браузера заданного размера).

В этом докладе речь шла о СУБД CUBRID от корейской компании NHN Corporation (по словам докладчика — ведущая IT-компания в Южной Корее и 13я по величине в мире). Начнем с того, что CUBRID — высокопроизводительная Open Source база данных (хотя кого сейчас этим удивишь), ориентированная под web-сервисы. SQL-синтаксис included (на 90% совместим с MySQL). Система зародилась исходя из потребностей управления огромным количеством баз данных (в докладе прозвучала цифра — 30 000 серверов, которые обслуживают более 150ти различных веб-сервисов).

В одном из первых слайдов промелькнул вопрос — мол нужно ли вообще использовать реляционные БД, когда вокруг столько «сладких» NoSQL-решений. Опираясь на тот факт, что такие успешные конторы, как Facebook, Twitter, Evernote и пр. используют РСУБД с шардированием для хранения больших объемов данных, то значит реляционные БД таки востребованы. Основная фишка, судя по заверениям авторов, состоит в том, что реализацию механизмов шардирования от CUBRID можно использовать не только с дефолтовым движком CUBRID, но также и с MySQL и даже с Oracle (правда вот с Oracle пока все же ещё нельзя, но по словам докладчика, в ближайших версиях точно появится).

Сам шардинг доступен начиная с версии 9.0 и по заверениям авторов делается очень легко. Шарды предсталвяют собой отдельно запущенные инстансы БД и некий CUBRID shard middleware. Конфигурирование шардинга с использование CUBRID сводится к редактированию 3х конфигурационных файлов:
1. проверить настройки в shard.conf — тут хранятся default-ные настройки CUBRID шардинга (куда писать логи и т.п.)
2. задать shard_connection.txt — заранее подготовленный список: номер шарда / имя DB / хост:порт коннекта к DB
3. задать shard_keys.txt — список ключей для шардирования и для каждого ключа трехколоночна «табличка»: min значение ключа, max значение ключа, номер шарда куда лезть за информацией
Как я понял, эти конфиги используются брокерами, входящими в состав CUBRID shard middleware. Лично мне не очень понятно, они настраиваются в одном месте, или же их надо rsync-а между несколькими серверами, выделенными под брокеры. Да и вообще не совсем ясно, как в этом случае реализована failover-схема, если все запросы идут через middleware — очевидно для middleware выделяется отдельная группа серверов.

Далее для завершения конфигурации следует настроить каждую отдельно взятую шарду и middleware. Это делается следующим образом — на каждом хосте с точностью до символа воспроизводятся три действия: 1. при помощи специальной утилиты создается база данных шарда и логин/пароль пользователя для доступа к ней 2. создается некая таблица, которую мы собираемся шардировать, и далее 3. запускается демон-контроллер. А в клиентском приложении задается connection URL для доступа к сформированному кластеру (адрес и порт, по которому расположен брокер, имя секции в shard.conf и логин-пароль). Брокер в свою очередь держит пул коннектов, разбирает пришедший запрос и адресует его на нужный шард, а так же отвечает за мониторинг всего кластера (тут могу ошибаться, возможно не сам брокер, а другая часть, входящая в состав middleware: proxy или CAS).

Касательно High Availability — для каждой шарды возможно включить master-slave репликацию (sync / async / semi-sync). В следующем релизе разработчики собираются добавить автоматическую перебалансировку данных (видимо нечто подобное перемещению чанков в MongoDB). И все бы хорошо, но у шардинга от CUBRID имеется ряд недостатков:

1. Распределённые транзакции между шардами естественно не работают
2. Нельзя использовать межшардовые JOIN-ы
3. Значение shard key не может быть обновлено. Хотите обновить поле с shard key — удалите и создайте запись заново.
4. Не поддерживаются агрегирующие запросы по всем шардам
5. Решение от CUBRID весьма ресурсоемко. Как сказал сам докладчик, на машине с 1 гб памяти производительность довольно слабая