Ноя
19
2012

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

По следам HighLoad++ 2012 (день второй, часть вторая)Заключительная статья про конференцию высоконагруженных систем HighLoad++ 2012 (предыдущие 3 части — тут, тут и тут). В статье речь пойдет про плагины для MySQL и MariaDB, про утилиту YSlow (которая по слухам активно используется в Twitter-e) и про корейскую разработку CUBRID и их реализацию шардинга «из коробки»

MySQL Plugins — why should I bother?

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

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

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

Proactive Web Performance Optimization (Twitter)

От докладчика из 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) и указать размеры «отображаемой» страницы (как если бы страница загружалась из окна браузера заданного размера).

Database Sharding the Right Way: Easy, Reliable, and Open source

В этом докладе речь шла о СУБД 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 выделяется отдельная группа серверов.

По следам HighLoad++ 2012 (день второй, часть вторая)Далее для завершения конфигурации следует настроить каждую отдельно взятую шарду и 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 гб памяти производительность довольно слабая

Комментарии (2)

  • Большое спасибо за обзор CUBRID! Ниже некоторые замечания и ответы на Ваши вопросы.

    … более чем 30 000 различных веб-сервисов компании.

    Точнее — 30 000 серверов, которые обслуживают более чем 150 веб-сервисов.

    Да и вообще не совсем ясно, как в этом случае реализована failover-схема, если все запросы идут через middleware — очевидно для middleware выделяется отдельная группа серверов.

    SHARD Broker может быть запущен либо на одном из серверов, на которых запущены шарды, либо на отдельном сервере. Сами базы/шарды, в том числе и SHARD брокеры, являются частью CUBRID Server. Т.е. сервер может иметь активные базы, может не иметь, также может иметь несколько брокеров, а может и не иметь. В зависимости от ресурсов разработчики должны решить отделять SHARD брокер от серверв, где находятся сами базы данных, или нет.

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

    В CUBRID есть два уровня failover. 1) на уровне сервера 2) на вровне брокера. Т.е. эта группа SHARD брокеров будут производить failover между собой. В приложении разработчик может указать список адресов брокеров. Если один из них не ответит в течение определенного времени, запрос автоматически передается второму брокеру и т.д.

    Лично мне не очень понятно, они настраиваются в одном месте, или же их надо rsync-а между несколькими серверами, выделенными под брокеры.

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

    Еще раз большое спасибо за обзор CUBRID! Если возникнут еще вопросы, буду рад ответить.

    Всего наилучшего!

    • Эсен, большое спасибо за подробный комментарий с разъяснениями :)

Оставить комментарий

CAPTCHA image


Поля, отмеченные * обязательны для заполнения


XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">