19
2012
По следам HighLoad++ 2012 (MySQL плагины, оптимизация при помощи YSlow, CUBRID)
MySQL Plugins — why should I bother?
Следующий доклад был от одного из разработчиков MariaDB (кто не в теме, MariaDB — это форк MySQL от самих разработчиков, после того, как Oracle поглотила Sun). Судя по прошлым их докладам на конференциях DevConf, вся суть сводилась к пиару СУБД MariaDB, и мне поначалу думалось, что тут будет нечто подобное. Но доклад оказался куда как интереснее (хотя и обзороного типа).
Вряд ли кто-то активно использует кастомные плагины для 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 выделяется отдельная группа серверов.
Далее для завершения конфигурации следует настроить каждую отдельно взятую шарду и middleware. Это делается следующим образом — на каждом хосте с точностью до символа воспроизводятся три действия: 1. при помощи специальной утилиты создается база данных шарда и логин/пароль пользователя для доступа к ней 2. создается некая таблица, которую мы собираемся шардировать, и далее 3. запускается демон-контроллер. А в клиентском приложении задается connection URL для доступа к сформированному кластеру (адрес и порт, по которому расположен брокер, имя секции в shard.conf и логин-пароль). Брокер в свою очередь держит пул коннектов, разбирает пришедший запрос и адресует его на нужный шард, а так же отвечает за мониторинг всего кластера (тут могу ошибаться, возможно не сам брокер, а другая часть, входящая в состав middleware: proxy или CAS).
Касательно High Availability — для каждой шарды возможно включить master-slave репликацию (sync / async / semi-sync). В следующем релизе разработчики собираются добавить автоматическую перебалансировку данных (видимо нечто подобное перемещению чанков в MongoDB). И все бы хорошо, но у шардинга от CUBRID имеется ряд недостатков:
- Распределённые транзакции между шардами естественно не работают
- Нельзя использовать межшардовые JOIN-ы
- Значение shard key не может быть обновлено. Хотите обновить поле с shard key — удалите и создайте запись заново.
- Не поддерживаются агрегирующие запросы по всем шардам
- Решение от CUBRID весьма ресурсоемко. Как сказал сам докладчик, на машине с 1 гб памяти производительность довольно слабая
Пн | Вт | Ср | Чт | Пт | Сб | Вс |
---|---|---|---|---|---|---|
« Сен | ||||||
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
Метки
Рубрики
- Apache (1)
- Highload (4)
- JavaScript (1)
- Linux (3)
- MongoDB (1)
- MySQL (1)
- Perl (1)
- PHP (5)
- Python (5)
- Web-разработка (5)
- Алгоритмы (1)
- За жизнь (2)
- Конференции (6)
Большое спасибо за обзор 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! Если возникнут еще вопросы, буду рад ответить.
Всего наилучшего!
Эсен, большое спасибо за подробный комментарий с разъяснениями