Это завершающий пост серии подробных статей про NoSQL-плагины для MySQL.
Итак, подведём первые итоги. Memcached использует уже хорошо стандартизированный и нейтральный к прикладным языкам протокол, содержащий на данный момент 40 команд и работающий на базе обмена обычными текстовыми строками.
В этом плане HandlerSocket очень похож по устройству на своего более именитого предшественника, за тем исключением, что использует только 6 команд. HandlerSocket также позволяет делать запросы как по составным ключам (используя массивы), так и актуальные ныне мультизапросы (т.е. несколько запросов на одно соединение), поэтому степень схожести этих двух протоколов достаточно велика.
Заметим, что уровень Handler API — точка сопряжения с движками, поэтому, очевидно, что HandlerSocket более универсален и теоретически способен работать с любым типом хранилища (на практике понадобятся минимальные переделки).
Принципиальная схема работы протокола HandlerSocket
Например, в Percona его удачно интегрировали с XtraDB. Остаётся только предположить, что такая низкоуровневая интеграция плагина Memcached в InnoDB была сделана для повышения скорости его работы (на один слой ниже, чем у HS).
Чтобы сразу расставить все точки над «i», я провел самостоятельную оценку производительности описанных плагинов.
Хочется сразу отметить некоторую субъективность и неизбежную погрешность подобных замеров: мельчайшие изменения настроек (например, увеличение количества потоков или даже замена сетевой карты на другую) приводят к существенной волатильности результатов в тестах, в силу этого все настройки оставлены мною по умолчанию.
Во время тестирования их работы стали заметны некоторые неоднозначности. Например, когда плагин Memcached работает в режиме cache & innodb store (включено собственное кэширование), записи параллельно кэшируются и на уровне буферов InnoDB. Такое дублирование, конечно, избыточно. В этом плане HandlerSocket кэширует только средствами движка данных, полагаясь в этом (и некоторых других вопросах) на собственную логику используемого хранилища MySQL.
Принципиальная схема работы протокола Memcached
Можно привести в пример ещё много подобных странностей со стороны плагина Memcached, но пока спишем это на его тестовое состояние. Другое интересное отличие: плагин Memcached не умеет делать FULL SCAN памяти (HS умеет, но с некоторыми оговорками).
innodb-only
(аналогичная роль с HS).
Для тестирования сочетания HandlerSocket/XtraDB использовался Percona Server версии query_cache_type = 0
, иначе результат будет браться из кеша и попадать в Qcache_hits вместо Com_select.
Итак, делая общий вывод по результатам тестирования: глядя на использование ресурсов системы, ещё раз ясно убеждаешься в том, что SQL — это очень «дорогой» интерфейс, его обход драматически увеличивает общую производительность системы (с одной стороны существенно повышая скорость выборок, с другой стороны — заметно понижая нагрузку на систему).
C этой точки зрения оба рассмотренных сегодня NoSQL-плагина действительно очень перспективны, при условии адекватно подобранного для них круга задач
Касаясь же персонально двух наших сегодняшних плагинов, в качестве заключения хочется ещё раз подчеркнуть: HandlerSocket, хоть и менее гибкий по широте своего применения и потенциальной функциональности плагин (в сравнении со своим визави Memcached), — но разработан он более качественно и работает эффективней. Как минимум это верно по состоянию на 2011-2012 годы, а что будет дальше — посмотрим.
Что ещё почитать по этой теме? Я рекомендую интересный видеодоклад Александра Календарева на конференции ADD-2011: здесь можно скачать полное видео его выступления + здесь доложена презентация к этому выступлению.
Впереди запланировано (и частично уже осуществлены) ещё множество уникальных обзоров и тестов, подписываемся на мой блог и узнаём обо всём первыми. Начало и оглавление этой серии статей — здесь.
6 комментариев
Простите за лемерский вопрос - я не очень хорошо знаком с внутренней архитектурой MySQL. С какой-то из этих двух механик - HS или Memcached -работает MySQL репликация? Или они обе работают после записи бинарного лога? Или обе до?
С HandlerSocket штатная репликация MySQL прекрасно работает и в любом режиме, - никаких фокусов или специфики. А вот насчет Memcached plugin - точно не знаю, не пробывал. Но чисто теоретически, наверное после бинлога должно работать тоже...
Кроме скорости, хотелось бы увидеть эффективность расходования памяти:
например, сравнить HandlerSocket с Redis.
На каких размерах данных HS перестает хватить буфера и начинается сильный io? И те же данные загнать в Redis и сравнить потребление.
Шикарная статья,
Хотелось бы увидеть еще тесты кластерных конфигураций.
Спасибо за Ваш цикл статей.
Смысл этих плагинов - скорость. Но приходится использовать их собственный интерфейс (библиотеку).
Также, поскольку это плагины к MySQL, можно использовать инструменты для MySQL (репликация, обслуживание) и традиционные SQL-команды. При этом скорость будет ниже, чем при использовании родного интерфейса.
Я правильно понял?
Алекс: в данном случае доступны параллельно два интерфейса:
1) стандартный/родной SQL (с какой угодно библиотекой, вероятно скорее всего со стандартной, то есть тут всё остаётся по прежнему, скорость как обычно, утилиты обычные и так далее),
2) и N0SQL-вариант (есть много готовых классов для большинства языков программирования, скорость будет ОЧЕНЬ высокой, но будет специфический режим выборок, суженных по возможностям в сравнении в SQL). Эти два варианта доступа доступны одновременно и на выбор клиента, к одной и той же физически БД и данным. Это всё если смотреть со стороны клиента...
С точки зрения сервера - после установки плагина и его настройки - всё также будет по-прежнему: доступны репликации, резервирование и прочее-прочее в полностью штатном режиме. Как клиент, так и админ после этого, могут даже не подозревать о наличии NoSQL-канала, - в этом-то и прелесть подобных гибридных решений, в их высокой степени адаптивности, когда не нужно отказываться от горы старого софта и стандартных решений.