Просмотров: 9359

MySQL: SQL или NoSQL - вот в чем вопрос. Тесты и выводы


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

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

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

Теперь давайте взглянем на схемы сопряжения плагинов ниже, которые показывают принципиальное устройство и работу этих двух плагинов. По ним хорошо видно, что HandlerSocket обращается к движку данных через уровень Handler API (данные в формате драйвера), тогда как плагин Memcached реализует максимально-возможный низкоуровневый доступ — напрямую к InnoDB API.

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

MySQL plugin плагин NoSQL HandlerSocket Memcached хранилище highload Drizzle NewSQL схема производительность замеры тест тесты скорость график таблица
Принципиальная схема работы протокола HandlerSocket

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

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

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

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

Я пытался воспроизвести условия и результаты тестирования автора HS (даже сервер по конфигурации подобрал почти аналогичный), но его значение в 750 000 rps я так и не достиг. Для сравнительного анализа скорости работы всех описанных интерфейсов предлагаю изучить Таблицу ниже.

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

MySQL plugin плагин NoSQL HandlerSocket Memcached хранилище highload Drizzle NewSQL схема производительность замеры тест тесты скорость график таблица
Принципиальная схема работы протокола Memcached

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

Примечания к тестированию плагинов
Тестирование проводилось на дефолтных настройках и полностью аналогичном оборудовании (сервер Nehalem 8 ядер с 32 Гб памяти, две сетевые карты). Единственная неоднородность была в версиях сервера БД: так как мне не удалось скомпилировать HandlerSocket под экспериментальными версиями MySQL 5.6.2 и 5.6.4, а InnoDB-MemcachedAPI реализован только в этих версиях, то для замеров HandlerSocket использовался последний MySQL 5.5. Плагин Memcached тестировался здесь в режиме innodb-only (аналогичная роль с HS).

Для тестирования сочетания HandlerSocket/XtraDB использовался Percona Server версии 5.5.15-21.0. На всех интерфейсах осуществлялось чтение (равнозначными для протоколов командами) из 500 000 записей, после нескольких повторений опыта все результаты усреднялись. Относительно HS есть ещё один тонкий нюанс — если будете проверять у себя, отключайте query_cache выставив query_cache_type = 0 , иначе результат будет браться из кеша и попадать в Qcache_hits вместо Com_select.

Общий вывод

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

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

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

MySQL plugin плагин NoSQL HandlerSocket Memcached хранилище highload Drizzle NewSQL схема производительность замеры тест тесты скорость график таблица

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

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

Игорь Савчук ©  Системный Администратор, 2011
twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru pikabu.ru blogger.com liveinternet.ru livejournal.ru google.com bobrdobr.ru yandex.ru del.icio.us

Подписка на обновления блога → через RSS, на e-mail, через Twitter
Теги: , , , , , , , , , ,
Эта запись опубликована: Вторник, 20 марта 2012 в рубрике Unix'овоеПрограммирование.

6 комментариев

Следите за комментариями по RSS
  1. Простите за лемерский вопрос - я не очень хорошо знаком с внутренней архитектурой MySQL. С какой-то из этих двух механик - HS или Memcached -работает MySQL репликация? Или они обе работают после записи бинарного лога? Или обе до?

  2. С HandlerSocket штатная репликация MySQL прекрасно работает и в любом режиме, - никаких фокусов или специфики. А вот насчет Memcached plugin - точно не знаю, не пробывал. Но чисто теоретически, наверное после бинлога должно работать тоже...

  3. Кроме скорости, хотелось бы увидеть эффективность расходования памяти:

    например, сравнить HandlerSocket с Redis.

    На каких размерах данных HS перестает хватить буфера и начинается сильный io? И те же данные загнать в Redis и сравнить потребление.

  4. Шикарная статья,

    Хотелось бы увидеть еще тесты кластерных конфигураций.

  5. Спасибо за Ваш цикл статей.

    Смысл этих плагинов - скорость. Но приходится использовать их собственный интерфейс (библиотеку).

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

    Я правильно понял?

  6. Алекс: в данном случае доступны параллельно два интерфейса:

    1) стандартный/родной SQL (с какой угодно библиотекой, вероятно скорее всего со стандартной, то есть тут всё остаётся по прежнему, скорость как обычно, утилиты обычные и так далее),

    2) и N0SQL-вариант (есть много готовых классов для большинства языков программирования, скорость будет ОЧЕНЬ высокой, но будет специфический режим выборок, суженных по возможностям в сравнении в SQL). Эти два варианта доступа доступны одновременно и на выбор клиента, к одной и той же физически БД и данным. Это всё если смотреть со стороны клиента...

    С точки зрения сервера - после установки плагина и его настройки - всё также будет по-прежнему: доступны репликации, резервирование и прочее-прочее в полностью штатном режиме. Как клиент, так и админ после этого, могут даже не подозревать о наличии NoSQL-канала, - в этом-то и прелесть подобных гибридных решений, в их высокой степени адаптивности, когда не нужно отказываться от горы старого софта и стандартных решений.

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

Не регистрировать/аноним

Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

Зарегистрировать/комментатор

Для регистрации укажите свой действующий email и пароль. Связка email-пароль позволяет вам комментировать и редактировать данные в вашем персональном аккаунте, такие как адрес сайта, ник и т.п. (Письмо с активацией придет в ящик, указанный при регистрации)

(обязательно)


⇑ Наверх
⇓ Вниз