Используем Couchbase Server вместо memcached

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 12:12, 27 июня 2018.

Под Memcached чаще понимают кеширующий сервер, когда как memcache — это расширение PHP, предназначенное для работы с этим сервером. Хотя, есть и memcached — расширение PHP. Чтобы не запутаться, распишем подробнее

  • Кеширующий сервер Memcached
  • Расширение Memcache
  • Расширение Memcached

Различия между этими двумя расширения небольшие

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

Однако, поэтому Memcache легче и производительней Memcached (судя по заявлениям специалистов, разница порядка 10%)

Существуют множество недостатков, которые являются причиной перехода с memcached на memcache. Ниже мы рассмотрим их поближе.

Memcached

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

Применяется он в основном для кэширования кода веб-страниц, результатов запросов к базе данных и тп. Также он мжет быть использован в качестве «не очень надежного» key-value хранилища. Например, в нем можно хранить сессии пользователей, коды капч или счетчик посетителей, находящихся в данный момент на сайте. При этом memcached крайне нетребователен к вычислительным ресурсам: на нагруженной инсталляции процессорное время, использованное им, редко превышает 10%.

В проекции веб-разработки это может помочь так: без кеширования один и тот же код будет генерироваться на сервере заново для каждого посетителя сайта. [Источник 1] На генерацию уходят ресурсы хостинга. Если посетителей становится много, это заметным образом сказывается на производительности системы. С помощью Memcached возможно один раз сгенерировать код сайта и хранить его результат в оперативной памяти, и когда очередной посетитель обратится к сайту, то хостинг, вместо того, чтобы генерировать всё заново, отдаст копию (кеш), хранящуюся в оперативной памяти. Логично, что чем больше нагрузка на сайт, тем больше пользы от Memcached. В итоге, используя кеширующий сервер, можно добиться двух целей сразу:

  1. Ускорение загрузку страниц;
  2. Уменьшение нагрузки на хостинг.

Couchbase Server

Couchbase Server - это механизм взаимодействия с базой данных. Он предоставляет быстрое хранилище ключей с управляемым кешем для операций ввода данных в миллисекундах, целенаправленные индексы для быстрых запросов и мощный механизм запросов для выполнения SQL-подобных запросов. Для мобильных и интернет-сетей Things Couchbase также запускается изначально на устройстве и управляет синхронизацией с сервером.

В двух словах о том, как работает Couchbase. Строго говоря, Couchbase является больше key-value базой данных, чем документо-ориентированной. Вся документо-ориентированность сосредоточена в клиентском API (есть библиотеки для Java, Си, .NET, Node.js, PHP, Python, Ruby, и других языков), а также возможности сервера пропарсить сохраненные значения для построения вторичных индексов и вьюх. Аналогом отдельной базы данных из мира РСУБД в Cocuhbase является бакет. Есть подозрения, что бакеты также можно использовать в качестве своего рода аналога таблиц, но официальная документация по Couchbase не рекомендует создавать более десяти бакетов. Бакеты бывают двух видов — Memcached-бакеты и Couchbase-бакеты.

Memcached-бакеты хранят все данные только в памяти и предназначены для кэшей и прочих данных, которые не страшно потерять. Couchbase-бакеты держат данные на диске. «Горячие» данные при этом кэшируются в памяти по принципу LRU. Используется собственная реализация кэша, не системный mmap. Плюс к этому Couchbase-бакеты могут реплицироваться на другие ноды. Один бакет может иметь от 1 до 3 реплик. Клиентские библиотеки поддерживают чтение как с мастера, так и с реплик.

Данные в Couchbase распределяются между узлами кластера равномерно. Для этого используются так называемые vBucket’ы, число которых задается при создании кластера и по-умолчанию равно 1024. Каждый узел в кластере является мастером или репликой определенных vBucket’ов. При чтении или записи документа, считается хэш от ключа. По этому хэшу определяется номер vBucket’а. Затем клиент по таблице, полученной от узлов кластера, смотрит, какие узлы в данный момент отвечают за этот vBucket, и обращается к ним. Через веб-админку можно запустить ребалансировку. В этом случае vBucket’ы будут перераспределены по кластеру, а клиенты, если во время ребалансировки они обратятся за документом не к тем узлам, будут перенаправлены на верные узлы.

В случае падения узлов кластера, переполнения дисков и других проблем, Couchbase отправляет письмо на указанные e-mail. По метрикам и логам, доступных в админке, можно диагностировать проблему. При падении одного из узлов, можно нажатием одной кнопки для vBucket’ов, оставшихся без мастера, выбрать нового мастера среди реплик, которые все еще доступны. Кроме того, поддерживается функция автоматического фейловера.

Надо отметить, Couchbase производит впечатление очень правильной БД, потому что:

Он не хуже Memcached, так как полностью поддерживает его протокол, умеет хранить значения размером до 20 Мб (только в Couchbase бакетах, в Memcached бакетах — до 1 Мб) и более предсказуемо ведет себя в граничных случаях вроде добавления узлов в кластер; Он не хуже Redis, так как может хранить данных больше, чем помещается в память, а также поддерживает автофейловер; Он не хуже MongoDB, поскольку до безобразия прост в настройке и поддержке, и к тому же использует память только под действительно полезные данные, а не все, что лежало поблизости с «горячим» документом, как в случае с mmap;

Couchbase Server служит для обеспечения управления данными с малым временем ожидания для широкомасштабных интерактивных веб-приложений, мобильных и приложений IoT. Общие возможности, которые Couchbase Server использует для обслуживание системы, включают:

  1. Единая программная среда (интерфейс программирования)
  2. Запросы
  3. Поиск
  4. Интернет вещей и мобильные устройства (Mobile and IoT)
  5. Аналитика
  6. Ядро базы данных
  7. Архитектура масштабирования
  8. Архитектура устройства памяти (Memory-first)
  9. Большие данные и их интеграция с SQL
  10. Full-stack безопасность
  11. Развертывание контейнеров и облаков
  12. High Availability

Основные преимущества Couchbase Server перед Memcached

Couchbase Server перед Memcached [Источник 2]
Проблема Симптомы Memcached Решения Couchbase Server
Cold Cache Замедление или сбой уровня обслуживания данных из-за сильно перегруженной СУБД, когда узлы memcached падают (при сбое или обслуживании) Данные автоматически реплицируются в кластере Couchbase, обеспечивая высокую доступность данных даже при сбоях
Серьезный RDMBS конфликт Несколько запросов к элементам данных, которые не существуют в кеше, приводят к внезапному смещению нагрузки в реляционную базу данных, что приводит к серьезным конфликтам Репликацией данных по кластеру Couchbase Server обеспечивает согласованную производительность без смещения нагрузки на уровень RDBMS
Отсутствие масштабируемости Добавление или удаление узлов memcached является сложным и приводит к непредсказуемой деградации производительности приложений Автоматическое масштабирование и онлайн-балансировка в Couchbase Server обеспечивает простое без разрушения расширение кластера
Комплексный мониторинг Управление отдельными узлами memcached увеличивает сложность операций и не имеет единого согласованного представления уровня кэширования Couchbase Server предоставляет встроенную консоль администратора для управления и мониторинга кластера, а также API RESTful для легкой автоматизации и сторонней интеграции

В отношении фичей Couhbase также справедливо следующее:

  • Поддерживается операция Flush. Она полностью удаляет содержимое бакета. По умолчанию Flush выключен. Включить его для заданного бакета можно в админке. Разработчики Couchbase категорически не рекомендуют использовать Flush для чего-либо, помимо очистки тестового окружения;
  • По умолчанию операция записи считается успешной, как только сервер обновил значение в памяти. Сохранение на диск и репликация происходят в фоне. Если сервер сразу после записи быстро ребутнется, данные вы потеряете. Если запишет на диск, но тут же на него упадет метеорит, прежде, чем произойдет репликация, то данные вы тоже потеряете. Клиентский API с помощью специальных флагов позволяет убедиться, что сделана запись на диск и/или произошла репликация на заданное количество нод прежде, чем запрос считается успешным;
  • У Memcached бакетов нет реплик, а следовательно и автофейловера. При падении машин часть данных в Memcached бакетах просто теряется;
  • Couchbase поддерживает значения-счетчики с атомарным увеличением и уменьшением на заданное число. Эти счетчики не могут быть отрицательными;
  • Есть CAS, а также пессимистичные локи, которые на самом деле представляют собой тот же CAS, только еще и запрещают доступ к документу другим пользователям. Если за указанный таймаут, до 30 секунд, документ не будет изменен, блокировка автоматически снимается;
  • У значений может быть TTL, а также, помимо операции set, этот TTL можно изменить операциями touch и getAndTouch;
  • Поддерживаются bulk-операции, позволяющие прочитать или изменить множество документов за одно хождение по сети;
  • Кроме того, есть операции append и prepand, атомарно дописывающие кусок данных в конец или начало документа;
  • Операция observe позволяет подписаться метаинформацию документа. Например, можно узнать, когда документ будет сохранен на диск или среплицирован на заданное число нод;
  • Couchbase умеет строить вьюхи, вычисляемые из оригинальных данных скриптами на JavaScript по принципу MapReduce. С их помощью можно строить индексы, в том числе и геопространственные. С этими вьюхами связан ряд ограничений. Они медленные, так как целиком лежат на диске. Они могут отставать от реальных данных. В них могут встречаться удаленные данные, а также данные с истекшим TTL;
  • В developer preview находится интерфейс N1QL (произносится «никель»), представляющий собой что-то вроде SQL-интерфейса для Couchbase. N1QL позволяет частично обновлять и считывать JSON-документы, работать с бакетом, как с одной большой таблицей в РСУБД, а также строить индексы, реализованные поверх упомянутых выше eventual consistent вьюх;
  • Репликация между ДЦ (XDCR) может быть односторонней, двусторонней и вообще любой. Вы просто говорите «реплицировать кластер А в кластер Б». С помощью этого примитива можно получить любую, сколь угодно сложную, топологию. Конфликты разрешаются в пользу более молодого документа, где молодость определяется по номеру ревизии, счетчику CAS, а также TTL. За счет последнего, например, реплицируется эффект от операции touch;
  • Существует Couchbase Lite, встраиваемая версия Couchbase для iOS и Android. Lite версия способна синхронизироваться с подмножеством данных с сервера, вызывать заданные хуки при приходе с сервера апдейтов, а также, в отличие от XDCR, делать merge конфликтующих документов самостоятельно написанным кодом;
  • Касательно автофейловера не все так классно. Как уже отмечалось, нужно по крайней мере три ноды. Если Couchbase видит что-то, что похоже на одновременное падение более, чем одного узла, автофейловер ничего не делает. Так сделано, чтобы в случае нетсплита случайно не выбрать двух мастеров для одного vBucket’а. Тем не менее, если в результате нетсплита только один узел будет отделен от всего остального кластера, автофейловер все-таки сработает. После восстановления сети этот узел обнаружит, что имел место автофейловер, и грохонет все локальные изменения данных. Впрочем, все это не так уж страшно, если вы не держите в Couchbase ничего такого, что нельзя потом пересчитать, или если вы хотя бы делаете бэкапы;

К сожалению, рассмотреть Couchbase более подробно не представляется возможным в рамках одной заметки.

Справочная архитектура

На приведенной ниже схеме архитектуры показана среда memcached до и после того, как уровень кэширования заменен сервером Couchbase.

Memcached архитектура против Couchbase Server

Один из вариантов использования Couchbase Server - функционировать как слой кэширования в типичной веб-архитектуре, как показано выше. Низкая латентность, согласованная производительность и линейная масштабируемость Couchbase Server делают ее подходящей заменой уровня memcache; его встроенная технология кеширования обеспечивает время ответа в миллисекундах, соответствующее времени memcached.

Данные в Couchbase Server автоматически разбиваются на разделы и распределяются между узлами кластера. Каждый узел кластера Couchbase идентичен, и данные реплицируются по узлам, так что каждый узел хранит как активные, так и реплики документов. Клиенты Couchbase имеют топологию и автоматически направляют запросы непосредственно на соответствующий узел.

Кроме того, консоль администратора в Couchbase Server позволяет отслеживать и управлять на уровне кластера (а не на уровне сервера, как и с memcached), упрощая управление и операции системы и экономя ваше время.

Установка Couchbase Server

В поле Hostname указываем private ip инстанса. Квоту по памяти я указал 10817 Мб из 16322 Мб доступных. Couchbase не позволяет использовать больше 80% от всей памяти в системе. Далее нам предложат создать тестовые наборы данных, отказываемся.

Затем создаем Memcached-бакет, скажем, размером 1 Гб. Обратите внимание, что это количество памяти будет выделено под бакет на каждой ноде. То есть, если у вас сейчас три ноды, всего под бакет в кластере будет выделено 3 Гб памяти. Если потом вы добавите еще ноду — то 4 Гб. Притом никого как бы не волнует, что ноды бывают немного разными. Учтите также, что квоту по памяти после создания можно изменить только у Couchbase бакетов, но не у Memcached бакетов!

Добавляем Memcached-бакет

Присоединяем вторую и третью ноду к кластеру. Заходим в админку аналогично тому, как делали это раньше. Теперь вместо «Start a new cluster» выбираем «Join a cluster now». После подключения всех нод идем во вкладку Server Nodes и жмем Rebalance.

Далее Settings → Auto-Failover → Enable auto-failover. Хорошим таймаутом, согласно документации, является 30 секунд. Если в вашем кластере раз в год ломается одна машина, с таким таймаутом вы получите «6 девяток», что должно быть за глаза практически любому проекту. Ставить таймаут меньше не имеет значения, так как вы получите те же «6 девяток», но с большей вероятностью ложного срабатывания автофейловера.

Установка таймаута

Собственно, это все, установка предельно проста! Развернуть и протестить кластер можно буквально за считанные минуты. Встроенный просмотр документов, метрики и мониторинг просто прекрасны, никаких Datadog’ов и Logentries’ов локально держать не нужно. Просто поставил и работает.

Заключение

Couchbase Server — многофункциональная система, обладающая рядом преимуществ перед Memcached, позволяющая организовать хранение данных как на одном узле, так и в форме распределённой системы, которая размещает данные поверх группы серверов. Есть встроенные средства для обеспечения высокой доступности, самовосстановления в случае сбоя обслуживающих хранилище узлов (данные могут дублироваться на разных узлах) и построения сегментированных хранилищ, копии которых разнесены по разным датацентрам. Поддерживаются как однонаправленные («ведущий — ведомый»), так и двунаправленные («ведущий — ведущий») режимы репликации. Поддерживается создание первичных и вторичных индексов, а также индексов по нескольким ключам. Для дополнительной оптимизации производительности применяются встроенные механизмы кэширования в оперативной памяти и средства автоматической генерации индексов. В общем и целом система отличная. За час времени можно понять, что система из себя представляет, поднять кластер и начать им пользоваться. В плане скорости Couchbase не хуже Memcached и Redis в ElastiCache, но при этом ощутимо дешевле. Дело в том, что в ElastiCache приходится платить отдельно за Memcached и отдельно за Redis, а Couchbase фактически предоставляет оба сервиса по цене одного. К сожалению, Couchbase из коробки не поддерживает работу с Set’ами и Map’ами, как это делает Redis, но их несложно реализовать самостоятельно поверх того, что есть.

Источники

  1. Что такое Memcached// Sheensay [2017]. URL: https://sheensay.ru/memcached (дата обращения: 27.06.2018).
  2. Replacing Memcached for Scalability. https://www.couchbase.com/memcached (дата обращения: 27.06.2018).