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

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

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

Этот пост — продолжение этой большой статьи, и здесь вы переходим от рассмотрения HandlerSocket к почти аналогичному по своим идеям, но во многом конкурирующему по своей реализации — плагину Oracle Memcached для MySQL.

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

Плагин Memcached

Было бы неправдой утверждать, что Memcached не был доступен в MySQL до недавнего выхода плагина-демона от компании Oracle, как минимум были доступны следующие варианты:

Использование Mycached.
Библиотека PECL PHP Memcached, которая существует сравнительно давно.
Несколько готовых Memcached UDFs.
Использовать MySQL Proxy для создания проброса через стандартный Memcached.
NDBAPI из арсенала MySQL Cluster. Кстати, благодаря Memcached теперь MySQL Cluster 7.2 GA способен также получать запросы через NoSQL C++ NDB API. Начиная с этой версии здесь есть новый NoSQL-интерфейс — родной API для memcached.
Использовать что-то из фреймворков, например Zend_Cache из популярного Zend Framework (который, кстати, позволяет использовать одновременно сразу несколько разных кэширующих систем).
Использовать горячую штучку от Google — Vitess, которая позволяет гибко настроить проброс в том числе в Memcached.
Использование libmemcached для создания интерфейса с MySQL.

И главное отличие нашего плагина от перечисленных вариантов, это именно прямой доступ к движку InnoDB в сочетании с интеграцией полной и родной функциональности Memcached, что в сумме и позволяет достигать именно той производительности, простоты и возможностей, которых так остро не хватало в вышеприведенных вариантах.

Судите сами: данный NoSQL-плагин от Oracle позволяет на выбор исполнять следующие три роли:

Он может делать то, что делает традиционный Memcached — использовать собственные хеш-таблицы в памяти для хранения данных (режим cache-only).
Обеспечивать прямой доступ к таблицам в движке InnoDB для чтения и записи туда данных (режим innodb-only).
Использовать свою собственную хеш-таблицу в памяти, и автоматически обращаться с дополнительным запросом к InnoDB, если в случае промаха данные сразу не были найдены непосредственно в кэше (режим cache & innodb store).

Единственная важная оговорка, что на текущий момент 2012 года, не все режимы работают как следует, и официально они доступны лишь в бета-версии MySQL 5.6.

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

Установка Memcached

Итак, после вводной порции теории предлагаю сразу перейти к практике: покажем, как можно установить плагин Memcached в MySQL 5.6.

Самый простой способ для этого — скачать уже готовую специализированную сборку, которые доступны для Linux, Solaris, MacOS X и даже Windows (среди доступных там в выпадающем списке бета-версий следует выбрать вариант mysql-5.6-labs-innodb-memcached ). После установки дистрибутива этой бета-версии MySQL, заходим в командную строку БД как root и запускаем скрипт, который сам настроит всё необходимое окружение, а после этого — выпускаем на волю демонический плагин:

mysql> scripts/innodb_Memcached_config.sql;
mysql> install plugin daemon_Memcached soname «libMemcached.so»;
mysql> set session TRANSACTION ISOLATION LEVEL read uncommitted;

В последней строчке, мы для перестраховки, вручную устанавливаем уровень транзакций, чтобы гарантировать, что увидим все последние добавленные в базу данные. Если вдруг возникли какие-то проблемы на каком-то из этих шагов, детали по этой установки можно найти в файле «README-innodb_Memcached », поставляемом вместе с указанным дистрибутивом.

Основы устройства протокола

Теперь, когда среда полностью настроена, давайте по аналогии с HandlerSocket проверим работоспособность нашего плагина (и заодно продемонстрируем всю простоту API Memcached), для чего сначала создаем тестовую таблицу:

mysql> INSЕRT INTО samag_test VALUES (’samag’,’it rules’, 10, 200, NULL).

После чего подключаемся к серверу с помощью telnet и пытаемся прочитать данные через интерфейс Memcached:

[savgor@corelink_6]$ telnet 69.25.27.173 11211
Trying 69.25.27.173...
Connected to 69.25.27.173.
Escape character is ’^]’.
get samag_test
VALUE samag 10 8
it rules
END

Как видите, вся кухня полностью готова к началу развертывания своего собственного NoSQL-сервера. Я не считаю здесь нужным более подробно останавливаться на демонстрации устройства и команд протокола Memcached (как это было сделано ранее по отношению к HandlerSocket), так как Memcached API прекрасно документирован и уже достаточно широко известен, но для тех кому это всё-таки в новинку, дам пару полезных внешних ссылок: это моя шпора по основным командам Memcached, а вот плавное введение в его идеологию, ну а здесь представлены основы его установки и использования (в данном случае на примере FreeBSD и Perl).

Memcached: действующие лица

В связи с множеством модификаций Memcached, хотелось бы сразу превентивно внести ясность в некоторую путаницу, которая иногда имеет место быть между зоопарком этих родственных проектов, а именно между: Mycached, Memcached, membase, Memcache, MemcacheQ, Memcacheddb и libMemcached.

Итак, центральный проект, любимчик движения NoSQL — Memcached. Это высокопроизводительная распределенная система кэширования объектов в оперативной памяти. Один из самых существенных минусов Memcached, что сам по себе кэш, которым он является, — очень ненадежное место хранения данных. Устранить это узкое место и призваны дополнительные решения: Memcacheddb и membase, — полностью на уровне интерфейса (API) совместимые с оригинальным проектом и технологически двигающиеся в сторону Redis. Здесь при устаревании данных они «свопятся» на диск (стратегия «db checkpoint »). В таком виде они представляют собой яркий пример «нереляционных баз данных» — персистентных систем распределённого хранения данных в виде пар «ключ-значение».

Следующая вариация, базирующаяся на коде того же центрального донора — MemcacheQ, — это система очередей сообщений, в которой реализован сильно упрощенный API от Memcached. MemcacheQ образует именованный стек, куда можно записать свои сообщения, а сами данные физически хранятся в БД BerkeleyDB (аналогично, как и в Memcacheddb), а значит, обеспечиваются условия их сохранности, реплицирования и другие возможности. LibMemcached — это известная клиентская библиотека, написанная на С++, для работы с уже стандартным протоколом Memcached. Впрочем, в качестве альтернативной библиотеки для PHP рекомендую использовать всё-таки memcache — она работает лучше LibMemcached.

Все нереляционные хранилища, выполненные в виде распределенной системы и хранящие пары «ключ-значение», можно подразделить на два типа: устойчивые и неустойчивые. Устойчивые (например, MemcachedB, membase, Hypertable) — сбрасывают данные на диск (иногда даже используют транзакционную модель). Неустойчивые же (классический Memcached) — хранят ключи в памяти лишь некоторое время (и не гарантируют их сохранность). Обычно, неустойчивые хранилища используют для кеширования и снижения нагрузки на устойчивые — в этом их неразрывная диалектическая связь.

Конструктивные особенности плагина Memcached

Поэтому, кратко ответив на вопрос «как», самое время перейти к логически вытекающему из него «зачем», — давайте рассмотрим преимущества и предназначение данной плагинной реализации Memcached.

Преимущества

Поддержка CRUD;
Поддержка уже готовых клиентов для протокола Memcached — не требуется полная переделка или создание новых клиентов как в ситуации с HandlerSocket. Добавим, что при этом доступны обе реализации протокола Memcached: как текстовый, так и бинарный. Оба интерфейса успешно проходят все без исключения тесты серии memcapable.
mysqld и Memcached работают в одинаковых процессах, с минимальным временем доступа к общим данным.
Обеспечивается прямой доступ к движку (InnoDB API).
Поддерживается запросы на нескольких колонок (в value можно выделить несколько колонок специальным символом-разделителем).
Также как и в HandlerSocket реализована поддержка пакетных операций: администратор сам может определять размер коммита для InnoDB-Memcached.
Реализован прозрачный перенос стандартных настроек Memcached через переменную MySQL (создаваемую данным плагином) — «daemon_Memcached_option »
Три режима работы — возможность выбора наиболее подходящей роли.
Наличие сборок под все основные ОС, в том числе оптимизированные билды под x32 и x64 для Windows.
Memcached изначально масштабируемый на несколько боксов, тогда как у HandlerSocket с этим могут быть проблемы.

Ограничения

Нет никакой безопасности (авторизация не предусмотрена).
Жесткая привязка к InnoDB engine .
Пока это только бета-версия (некоторые режимы до конца не готовы, плагин находится в стадии активного тестирования и доработки).

Читать этот материал дальше. Оглавление этой серии статей — здесь.