Blogerator.org

× Версия для печати

Это завершающий пост серии подробных статей про NoSQL-плагины для MySQL.

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

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

Заметим, что уровень Handler API — точка сопряжения с движками, поэтому, очевидно, что HandlerSocket более универсален и теоретически способен работать с любым типом хранилища (на практике понадобятся минимальные переделки).

Принципиальная схема работы протокола HandlerSocket

Например, в Percona его удачно интегрировали с XtraDB. Остаётся только предположить, что такая низкоуровневая интеграция плагина Memcached в InnoDB была сделана для повышения скорости его работы (на один слой ниже, чем у HS).

Тесты производительности: Memcached vs. HandlerSocket

Чтобы сразу расставить все точки над «i», я провел самостоятельную оценку производительности описанных плагинов.

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

Во время тестирования их работы стали заметны некоторые неоднозначности. Например, когда плагин Memcached работает в режиме cache & innodb store (включено собственное кэширование), записи параллельно кэшируются и на уровне буферов InnoDB. Такое дублирование, конечно, избыточно. В этом плане HandlerSocket кэширует только средствами движка данных, полагаясь в этом (и некоторых других вопросах) на собственную логику используемого хранилища MySQL.

Принципиальная схема работы протокола Memcached

Можно привести в пример ещё много подобных странностей со стороны плагина Memcached, но пока спишем это на его тестовое состояние. Другое интересное отличие: плагин Memcached не умеет делать FULL SCAN памяти (HS умеет, но с некоторыми оговорками).

Общий вывод

Итак, делая общий вывод по результатам тестирования: глядя на использование ресурсов системы, ещё раз ясно убеждаешься в том, что SQL — это очень «дорогой» интерфейс, его обход драматически увеличивает общую производительность системы (с одной стороны существенно повышая скорость выборок, с другой стороны — заметно понижая нагрузку на систему).

C этой точки зрения оба рассмотренных сегодня NoSQL-плагина действительно очень перспективны, при условии адекватно подобранного для них круга задач

Касаясь же персонально двух наших сегодняшних плагинов, в качестве заключения хочется ещё раз подчеркнуть: HandlerSocket, хоть и менее гибкий по широте своего применения и потенциальной функциональности плагин (в сравнении со своим визави Memcached),  — но разработан он более качественно и работает эффективней. Как минимум это верно по состоянию на 2011-2012 годы, а что будет дальше — посмотрим.

Что ещё почитать по этой теме? Я рекомендую интересный видеодоклад Александра Календарева на конференции ADD-2011: здесь можно скачать полное видео его выступления + здесь доложена презентация к этому выступлению.

Впереди запланировано (и частично уже осуществлены) ещё множество уникальных обзоров и тестов, подписываемся на мой блог и узнаём обо всём первыми. Начало и оглавление этой серии статей — здесь.

Игорь Савчук ©  Системный Администратор, 2011