По следам HighLoad++ 2012 (RabbitMQ плагины, аналитика больших данных в Etsy.com, Percona XtraBackup)

Второй день конференции начался с доклада Альваро Видела (кстати, он же соавтор бестселлера RabbitMQ in Action) о том, как круто можно расширять базовую функциональность RabbitMQ через самописные плагины на Erlang-е (кто не в курсе, RabbitMQ — это весьма крутой AMQP-брокер сообщений, пользуемый такими гигантами интернета, как Twitter или Digg). К сожалению, не знаю Erlang-а (а на других языках писать плагины нельзя), да и с RabbitMQ знаком очень поверхностно (приходилось ковыряться, но не более), поэтому этот доклад для меня был не очень интересен. Если сильно интересно, то вот сюда Альваро выложил все тезисы и презентацию, и можно побольше почитать про это все дело. Для себя я выделил следующие моменты:

1. Существуют как официальные плагины, так и неофициальне плагины от коммьюнити
2. При помощи плагинов можно протюнить RabbitMQ: добавить новый протокол (например STOMP), создать мост между собственным протоколом и AMQP, добавить аутентификацию (LDAP, SSL), создать собственное message store заместо default-ового, например, на основе redis или postrges (но тут надо быть предельно внимательным и для начала хотя бы изучить вот эту статью, брокер сообщений должен пропускать порядка 10000 сообщений в секунду, и персистентное хранилище должно удовлетворять подобному требованию).
3. При помощи плагинов можно изменять механизмы доставки сообщений. Так можно написать специальный плагин, чтобы, добавлять сообщение сразу в несколько очередей в зависимости от routing key. Или же кидать сообщение в случайно выбранную очередь (см. плагин random-exchange). Чтобы поддерживать историю сообщений можно воспользоваться плагином riak-exchange (т.к. из коробки RabbitMQ не позволяет просматривать сообщения в очереди). В случае, если мы пишем чат, и каждый подключившийся пользователь должен получать последние несколько сообщений, отправленных в чат, можно воспользоваться плагином recent-history-exchange, который позволяет хранить последние 20 сообщений, вне зависимости от очереди получателя.

Есть такой западный e-commerce ресурс, специализирующийся на продаже всяческих рукоделий и хэндмейдов, называется Etsy.com. Признаться, мало что слышал про этот сайт. Но судя по тому, что в разработке проекта участвует примерно две сотни инженеров, среди которых люди, кто делал Flickr, а так же (о боже!) создатель PHP Расмус Лердорф, то проект достаточно крутой. В докладе Database Engineer этого ресурса рассказывал как эволюционировал их продукт в плане нагрузок, а так же как они обсчитывают аналитику.

Начинали с того, что на фронтенде использовали PHP, на бэкенде Python фреймворк Twisted и в качестве базы данных PostgreSQL (активно использовали хранимые процедуры). Причем начинали с одной master БД. С разрастанимем бизнеса пришлось разносить различные компоненты БД по разным PostgreSQL серверам. Счетчики просмотров хранили в памяти, и при перезагрузке сервера они терялись, так что их тоже пришлось вынести в Postgres на отдельном сервере. Для поиска использовали сначала встроенный в Postgres Full Text Search, но потом отказались от него в пользу специализированного инструмента Apache SOLR. Несмотря на это, уткнулись в ряд проблем (в частности с поиском инженеров, которые бы разбирались одновременно в PHP, в Python и умели бы писать Postgres процедуры).

В итоге выпустили 2ую переработанную версию своего продукта:

• Полностью отказались хранимых процедур в БД
• Переработали фронтенд часть — написали свою PHP-бибилотеку EtsyORM для работы с бизнес-логикой на фронтенде, начали использовать PHP-шаблонизатор (тут не очень понятно, как было раньше и что конкретно использовали для шаблонизации)
• Увеличили AJAX-функциональность
• Заменили Postgres на MySQL (я так понял, выбор в пользу MySQL был сделан преимущественно из-за того, что к проекту подключились ребята из Flickr, у которых был обширный опыт «приготовления» MySQL, и в частности — шардирования, что позволило уйти от единственной master-базы Postgres-а).

После перехода к версии 2 вообщем-то все стало хорошо, но возник вопрос как агрегировать шардированные данные для обсчета аналитики и т.п. Сначала для агрегации и MapReduce использовали Hadoop, по получили ряд проблем:

• Hadoop ориентирован на пакетные задачи и не очень хорош для отдельных запросов
• Программирование задач для Hadoop — путь проб и ошибок, довольно утомительное занятие и занимает много времени
• Hadoop-задачи это специальные программируемые task-и, что не очень подходит для бизнес-аналитиков
• В случае задач, где ответ нужен моментально, Hadoop не очень подходит

Таким образом, для решения определенного ряда реал-тайм задач бизнес аналитики в etsy.com начали использовать колоночную БД Vertica:

• создана папой Postgres-а, примерно год назад была куплена компанией Hewlett Packard
• имеет богатый SQL-подобрый язык
• хоть и платная, но возможно бесплатное использование на одной ноде и до 1 терабайта данных
• в базовой поставке работает на нескольких равнозначных узлах
• шардинг прямо из коробки
• Vertica размещает копии маленьких таблиц на каждой ноде, а вот сегменты больших таблиц распределяет между нодами согласно встроенному алгоритму (делает это прозрачно для пользователя и за счет этого предельно легка в управлении).

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

Percona XtraBackup предоставляет механизм «продвинутых» бэкапов и работает для следующих БД: MySQL 5.0, 5.1, 5.5, Percona Server 5.0, 5.1, 5.5 а так же MariaDB 5.1, 5.5.

Доклад начался с того, как устроен движок InnoDB и как это устройство соотносится с XtraBackup. В отличии от встроенного средства mysqldump, которое делает lock таблицы на запись во время бэкапа, XtraBackup от Percona создает бэкап в неблокирующем режиме. Однако тут стоит отметить, что в случае нетранзакционных движков, таких как MyISAM, таблица-таки блокируется:

FLUSH TABLES WITH READ LOCK

Есть возможность делать инкрементальные бэкапы (но правда первый бэкап должен быть неинкрементальным, и несмотря на малый размер для создания такого рода бэкапа приходится производить скан всех данных в таблице). В отличии от стандартной утилиты, которая по сути делает текстовые SQL-бэкапы, XtraBackup создает копии файлов таблиц и текущего бинлог и практически не грузит систему.

В составе утилиты имеется ряд полезных и не очень фич, таких как:

• поддержка потокового режима
• компрессия и шифрование на лету (встроенная компрессия, в отличии от использования внешних утилит, может быть распаралелена по ядрам)
• копирование на другой хост во время бэкапа

Так же для оптимизации производительности имеется ряд полезных опций, таких как, например, ограничение скорости копирования блоков. Чтобы не забить дисковый кэш можно указать опцию, чтобы данные не кэшировались. Имеется опция для параллельного копирования блоков. Для восстановления также присутствует большое количество настроек (к примеру, из бэкапа можно восстановить только отдельные таблицы).