🐟

IMDG

IMDG - In-Memory Data Grid - это распределенная база данных, в которой хранение происходит не на диске, а в оперативной памяти.

Для того чтобы сохранить данные при различных инцидентах, хранилище делают распределенным, собирая кластер из нескольких инстансов.

Кластер самостоятельно занимается распределением данных по инстансам (шардирование). Для того чтобы данные не были потеряны при вылете одной из нод, шардированные данные реплицируются на других нодах.

Когда нужна IMDG

Необходимость в использовании IMDG возникает, когда требуется обеспечивать низкую latency при высоком throughput, и быстродействие системы начинает упираться в низкую скорость вычитки данных из обычных реляционных БД. IMDG обещает увеличение скорости чтения / записи данных более чем в 1000 раз.

Основные представители

Split Brain

Ситуация, когда ноды IMDG теряют между собой связь (обрубился сетевой провод) и перестают быть единым кластером, называется Split Brain.

В этой ситуации возможно, что разные приложения будут изменять одни и те же данные в разъединенных кластерах. После воссоединения кластера необходимо разрулить конфликты в данных. Для этого при конфигурации IMDG задаются стратегии мержа.

Hazelcast IMDG

Hazelcast IMDG может быть развернут несколькими способами:

  • Embedded - когда hazelcast поднимается внутри приложения. Обычно используется для тестирования.
  • Client/Server - инстансы hazelcast поднимаются независимо от основного приложения. Такая архитектура дает дополнительные затраты на доставку сообщений, но позволяет масштабировать хранилище независимо от приложения
  • Cloud - то же самое, что Client/Server, но не нужно иметь свое железо

Hazelcast IMDG реализует стандарт JCache и может использоваться в качестве распределенного кэша через его API.

Структуры данных

Hazelcast предоставляет множество различных структур данных, но основной из них является мапа ключ-значение.

Настройка Hazelcast

Все настройки Hazelcast производятся через специальный файл hazelcast.xml, который идет в комплекте поставки.

Контроль над памятью

Так как объем оперативной памяти по сравнению с памятью на диске существенно ограничен, то необходимо самостоятельно контролировать заполнение кластера данными. Здесь приходится либо самостоятельно удалять данные, которые уже не требуется хранить, либо задавать time-to-live на определенные мапы.

Рекомендуется не заполнять кластер данными более чем на 60 %. Если превысить это значение, то существенно уменьшается быстродействие кластера при перераспределении данных между нодами, и возникает риск падения всего кластера при выходе из строя одной ноды.

Hazelcast Client

Взаимодействие с кластером Hazelcast в Java-приложениях производится через специальную библиотеку hazelcast-client.

При этом работа с Hazelcast почти не отличается от работы с обычной мапой. Только эта мапа находится не в памяти самого приложения, а в отдельном кластере.

В приложениях, построенных на Spring, Hazelcast Client или даже отдельные мапы выносятся в отдельный singleton бин.

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

Мониторинг Hazelcast

Мониторинг состояния Hazelcast можно производить несколькими способами:

  • REST API
  • JMX

REST API

Hazelcast предоставляет REST интерфейс для получения информации о Hazelcast. По умолчанию он выключен, и его включение производится через hazelcast.xml. REST интерфейс используется для верхнеуровнего мониторинга состояния кластера и позволяет читать и писать одиночные записи.