In memory data grid сравнение

Обновлено: 24.01.2025

GigaSpaces eXtreme Application Platform (XAP) - распределенная сеть данных в памяти подходящая для высокопроизводительной обработки с низкой задержкой так же, как и в случаях использования методов аналитики в режиме реального времени.

Обзор

Особенности

Производительность XAP достигается за счет максимального использования ОЗУ и SSD в качестве основного хранилища данных. Он обычно используется для ускорения производительности и масштабируемости существующей базы данных и включает встроенную синхронизацию с RDBS, такую как MySQL, а также MongoDB, Cassandra и т. д. XAP была разработан, чтобы служить в качестве системы записи для данных, которые она поддерживает. Таким образом, он поддерживает все функции баз данных, такие как сложные запросы, поддержка транзакций и т. д. Среди его основных функций - поддержка широкого спектра моделей данных, начиная с простого ключа, API значения для продвижения агрегации, поддержки объектов и поддержки SQL.. [Источник 1] .

Flash обеспечивает высокоскоростное хранилище данных. XAP использует комбинацию RAM и Flash для оптимизации как скорости, так и требования к стоимости. Поддержка Flash известна как XAP MemoryXtend и обеспечивает в 50 раз больше емкости, чем RAM для того же количества компьютеров.

XAP в сравнении с простым кэшированием, таким как Memcache

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

Большинство новых решений NoSQL используются в качестве альтернативной базы данных для традиционных СУБД. Базы данных NoSQL используют комбинацию возможной согласованности и масштабируемости для обработки их масштабируемости и производительности. XAP, с другой стороны, был разработан для решения проблемы масштабируемости и производительности существующей базы данных, обращаясь к базе данных с хранилищем данных в памяти. Хранилище данных в памяти обеспечивает высокоскоростной доступ к данным для той части данных, которая в ней нуждается. Она включает встроенную синхронизацию с базами данных типа NoSQL и RDBMS для загрузки данных после восстановления и синхронизации базы данных при обновлении данных. С точки зрения архитектуры существует много общего между XAP и другими базами данных NoSQL. Оба используют масштабируемую модель для обеспечения ее масштабируемости. В отличие от NoSQL, XAP использует высоконадежный и транзакционный доступ к данным и, следовательно, может служить высокоскоростным транзакционным интерфейсом для баз данных BackSquare NoSQL.

В наши дни XAP используется для комплексной обработки событий и бизнес-аналитики реального времени для больших данных. С помощью XAP вы можете реплицировать данные в реляционную базу данных или нереляционную базу данных NoSQL, позволяя репликацию данных на удаленных сайтах через WAN, для восстановления после сбоев и также cloud-ready. [Источник 2]

Отличия In-Memory Data Grid и In-Memory Database

Большинство In-Memory Database - это СУБД, которые хранят данные «в памяти», а не на диске. Они обеспечивают хорошую поддержку SQL только с небольшим списком неподдерживаемых функций SQL, поставляются с драйверами ODBC / JDBC и могут использоваться вместо существующих СУБД, часто без существенных изменений.

В In-Memory Data Grid обычно отсутствует полная поддержка ANSI SQL, но вместо этого они предоставляют возможности на основе MPP (Massively Parallel Processing), где данные распределяются по большому кластеру обычных серверов и обрабатываются явно параллельным способом. Основным шаблоном доступа является доступ по ключу / значению, MapReduce, различные формы HPC-подобной обработки и ограниченные возможности запросов и индексирования распределенного SQL.

Важно отметить, что существует значительный переход от In-Memory Data Grid к In-Memory Database с точки зрения поддержки SQL. GridGain, например, предоставляет довольно серьезную и постоянно растущую поддержку SQL, включая подключаемую индексацию, оптимизацию распределенных объединений, пользовательские функции SQL и т. д.

Одно из важнейших различий заключается в возможности масштабирования до сотен и тысяч серверов. Это является неотъемлемой возможностью In-Memory Data Grid для такого масштаба из-за их архитектуры MPP и явной неспособности In-Memory Database масштабироваться из-за того, что объединения SQL, как правило, не могут быть эффективно выполнены в контексте распространения. Одна из их самых полезных функций, SQL-соединения, это также их ахиллесова пята, когда речь заходит о масштабируемости. Это фундаментальная причина, по которой большинство существующих баз данных SQL (на основе дисков или памяти) основаны на вертикально масштабируемой архитектуре SMP (симметричная обработка), в отличие от In-Memory Data Grid, которые используют гораздо более горизонтально масштабируемый подход MPP.

Важно отметить, что обе системы могут достигать одинаковой скорости в локальном нераспределенном контексте. В конечном итоге - они делают всю обработку в памяти. Но только In-Memory Data Grid в оперативной памяти могут масштабироваться до сотен и тысяч узлов, обеспечивая беспрецедентную масштабируемость и непревзойденную пропускную способность.

Помимо масштабируемости, есть еще одно отличие, которое важно для случаев использования, когда In-Memory Data Grid или IMDB (In-memory Database) выполняет задачи по ускорению работы существующих систем или приложений.

In-Memory Data Grid всегда работает с существующей базой данных, обеспечивая слой массивно распределенного хранения в памяти и обработки между базой данных и приложением. Затем приложения используют этот уровень для сверхбыстрого доступа к данным и их обработки. Большинство In-Memory Data Grid могут при необходимости беспрепятственно считывать и записывать из баз данных и в них и, как правило, тесно интегрированы с существующими базами данных.

В обмен на это разработчики должны внести некоторые изменения в приложение, чтобы воспользоваться этими новыми возможностями. Приложение больше не «говорит» только на SQL, но ему нужно научиться использовать MPP, MapReduce или другие методы обработки данных.

In-Memory Database дают почти зеркальную противоположную картину: они часто требуют замены существующей базы данных (если только вы не используете один из этих «параметров» в памяти для временного повышения производительности базы данных), но потребуют значительно меньших изменений в самом приложении, поскольку он будет по-прежнему полагаться на SQL (хотя и на его модифицированный диалект). [Источник 3]

Таблица 1. Сравнение систем

Системная особенность	In-Memory Data Grid	In-Memory Database
Приложение	Изменяемое	Неизменяемое
РСУБД	Неизменяемое	Изменяемое
Скорость	Да	Да
Максимальная масштабируемость	Да	Нет

В конце концов, оба подхода имеют свои преимущества и недостатки, и зачастую они могут зависеть отчасти от организационной политики и политики, а также от их технических достоинств. Любой продукт, перед которым стоят проблемы масштабируемости и производительности, может выиграть от использования In-Memory Processing и IMDG архитектуры.

Содержание

Перспектива компонентов XAP

OpenSpaces

Open Spaces - основная платформа для разработки приложений в GigaSpaces. Open Spaces использует Spring в качестве инфраструктуры разработки, основанной на POJO, и добавляет компоненты времени выполнения и разработки для разработки приложений на основе EDA / SOA на основе POJO и масштабирует их просто через пул машин без зависимости от контейнера J2EE. Для достижения этих целей Open Spaces добавляет следующие компоненты в среду разработки Spring: Process Unit - основной блок работы. Инкапсулирует промежуточное ПО вместе с бизнес-логикой в единое целое масштабирования и отказоустойчивости. SLA-Driven Container - легкий контейнер, который позволяет динамическое развертывание модулей обработки над пулом машин на основе доступности машины, использования процессора и других критериев аппаратного и программного обеспечения. In-Memory Data Grid - обеспечивает распределенное хранение данных в памяти. Контейнеры декларативных событий - для запуска событий из пространства в POJO в режиме pull или push. Remoting - использует пространство в качестве основного транспорта для вызова удаленных методов в службах POJO внутри модуля обработки. Такой подход позволяет клиенту вызывать методы на службе, даже если он изменяет физическое местоположение и позволяет перенаправлять запросы к доступным службам в случае перехода на другой ресурс. Декларативная поддержка транзакций для грид-данных GigaSpaces.

Core Middleware

Средства виртуализации промежуточного ПО XAP:'

Контейнер с SLA-Driven

Контейнеры с SLA-управлением (известные также как Grid Service Containers или GSC), позволяют развертывать модули обработки по динамическому пулу машин на основе определений SLA. Каждый контейнер представляет собой процесс Java, который обеспечивает среду хостинга для прикладных сервисов, входящих в состав модуля обработки. Контейнер виртуализирует основные вычислительные ресурсы и выполняет сопоставление между временем выполнения приложения и базовыми ресурсами на основе критериев SLA, таких как использование ЦП и памяти, аппаратная конфигурация и доступность программного обеспечения (JVM, DB и т. Д.). Он также обеспечивает возможности самовосстановления для обработки сбоев или масштабирования событий.

С помощью XAP экземпляры IMDG создаются из экземпляров пространства. IMDG может быть развернут точно так же, как и любая другая служба, в составе модуля обработки. Это дает возможность связать определения SLA с IMDG. Общее использование заключается в перемещении экземпляров IMDG на основе использования памяти; другое использование заключается в использовании определений SLA для обработки развертывания различных топологий IMDG в тех же контейнерах. Контейнеры с SLA-приводом также могут добавлять характеристики самовосстановления. Когда один контейнер сбой, неудавшиеся экземпляры IMDG автоматически переносятся в доступные контейнеры, обеспечивая приложению постоянную высокую доступность.

Runtime-перспектива

С точки зрения времени выполнения кластер XAP представляет собой кластер машин, каждый из которых запускает один или несколько экземпляров контейнеров с SLA-Driven. Контейнеры несут ответственность за предоставление аппаратных ресурсов приложениям XAP. Приложение, работающее с XAP, построено из нескольких модулей обработки. Единицы обработки упакованы как часть пакета; структура связки совместима с Spring / OSGI. Каждый комплект содержит дескриптор развертывания с именем pu.xml, файл контекста приложения Spring с расширениями компонентов Open Spaces. Этот файл содержит определение SLA модуля обработки, а также ассоциации между компонентами приложения, а именно POJO-сервисы, компоненты промежуточного программного обеспечения и, чаще всего, Data Grid. Приложение развертывается через GSM (Grid Service Manager), который выполняет сопоставление между определениями SLA обрабатывающего модуля приложения и доступными контейнерами, управляемыми SLA. Определения SLA включают количество экземпляров, которые необходимо развернуть, количество экземпляров, которые должны запускаться для каждого контейнера и по всей сети, и системные требования, такие как требуемая версия JVM или версия базы данных. Различные приложения могут иметь один или несколько экземпляров своих модулей обработки, работающих в одном и том же контейнере в одно и то же время. Несмотря на то, что приложения имеют один и тот же экземпляр JVM, они изолируются через загрузчики классов приложений.

SOA/EDA-перспектива

Перспектива удаленного клиента

Режимы взаимодействия

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

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

В XAP этот способ взаимодействия может быть достигнут двумя способами:

Посредством непосредственного взаимодействия с пространственным интерфейсом. В этом случае операция записи в пространстве является эквивалентом update / put или insert; операция чтения является эквивалентом выбора; и операция уведомления является эквивалентом триггера.
Использование оберточных фасадов, предоставляемых GigaSpaces, таких как интерфейс JCache / Map или JDBC-драйвер, которые выполняют это сопоставление неявно.

В XAP этот способ взаимодействия может быть достигнут двумя способами:

Взаимодействуя непосредственно с пространственным интерфейсом. В этом случае операция записи эквивалентна отправке, а операция оповещения или принятия эквивалентна получению или подписке соответственно.
Использование интерфейса JMS, который предоставляется в качестве оболочки поверх API пространства, и отображает между операцией JMS и требуемыми космическими операциями.

Синхронный по своей природе - на основе взаимодействия запрос-ответ. Тип-безопасный - обеспечивает безопасность типа операции и аргументы во время компиляции, поскольку она напрямую связана с интерфейсом удаленного сервиса. В XAP этот способ взаимодействия достигается путем дистанционной дистанции. Этот метод использует тот факт, что пространство уже открыто как удаленный объект и имеет существующий механизм виртуализации, чтобы включить удаленный вызов для служб, которые распределены по нескольким модулям обработки, возможно, запущены на нескольких физических машинах.

С дистанционным удалением пространства - удаленный заглушка, созданный для удаленной службы, с использованием динамических прокси. Когда метод вызывается в этом прокси, заглушка неявно отображает его в команде, которая записывается в это пространство и направляется на соответствующий экземпляр сервера. На стороне сервера общий делегат принимает эти команды и выполняет метод в конкретном экземпляре компонента, основываясь на имени метода и аргументах, представленных в команде. Результат также возвращается через пробел, принимается динамическим прокси и прозрачно возвращается клиенту в качестве возвращаемого значения метода. [Источник 3] .

Фото модуля памяти на магнитных сердечниках в мейнфрейме IBM 1401, использованное в качестве фона на этом изображении, напоминает нам о временах, когда компьютеры были большими, а память — дорогой. Сегодня, как мы узнаем из поста ниже, все поменялось.

IMDG, гриды, In-Memory Data Grids — как только не называют системы, которые оказались темой поста. И хотя название совершенно правдиво, да и гриды, как инструмент, всё более популярны, многие до сих пор путают их то с системами распределённых кэшей, то с NoSQL-базами данных, а то и вовсе полагают, что «если разместить MySQL на RAM-диске, то получится почти IMDG».

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

Рост числа пользователей онлайн-сервисов, массовое распространение социальных сетей, появление и развитие интернета вещей, развитие услуг в секторах банкинга и телекома — всё это повлияло на IT-индустрию вполне предсказуемым образом: число транзакций резко выросло, хотя требования ко времени выполнения каждой из них только ужесточились, а никаких чудесных решений, работающих «из коробки», долгое время не появлялось. Другими словами, требование времени звучало как «делай как хочешь, но делай быстрее, иначе бизнесу несдобровать!»

Сначала выдержать рост числа запросов к веб-приложениям успешно помогали облака: идея масштабирования вычислительных мощностей в облаке потребовала, конечно, поддержки и учёта в коде приложений, но, по крайней мере, стало понятно, что приложение не упрётся в возможности железа по процессору и памяти. А вот с хранением обрабатываемой информации дело оказалось более сложным, потому что привычные варианты такого хранилища (например, классическая SQL-СУБД), в свою очередь, постепенно оказывались узким местом всей системы. Приложение, все вычислительные ноды которого (сколько бы автомасштабирование ни подняло таких нод) ждут ответа от SQL-сервера, представляет, прямо скажем, душераздирающее зрелище!

Конечно, хороший архитектор и в такой, патовой, ситуации постарается построить работающую систему (отсюда получим кэши на каждом потоке данных, обвязки для их инвалидации, NoSQL-сервера в добавок или на замену их SQL-предшественников, переписывание логики приложения с учётом перечисленного; как ни крути, есть чем заняться всей команде!), но, согласитесь, хотелось бы, конечно, решение «самую чуточку попроще».

Здесь-то на сцену и вышли IMDG-решения, соединившие в себе и кэширование, и NoSQL-подходы, и распределённый подход (чаще даже распределённый через WAN, а не только по локалке) к построению системы. По сути своей, это кластерные хранилища данных, причём модель данных может быть объектной или с хранением по ключам (key-value). Эти хранилища обладают парой откровенно «волшебных» свойств: способностью надёжно хранить данные в совершенной ненадёжной среде — в ОЗУ — и умением обрабатывать данные прямо в памяти, без предварительного сохранения их на диск и дальнейшего вычитывания заново.

Модель хранения данных гридов построена по принципу «ничего общего» (shared nothing) и предполагает распределение данных между множеством физически разнесённых серверов. Все серверы, входящие в IMDG, равнозначны, и все данные хранятся в их оперативной памяти. При этом конструкция грида является отказоустойчивой с возможностью автоматического обнаружения вышедших из строя серверов, и при необходимости (скажем, для изменения объёмов оперативной памяти грида) серверы могут подключаться или отключаться без нарушения работы инфраструктуры грида.

Уже описанных свойств должно хватить, чтобы привлечь к идее IMDG внимание архитекторов крупных систем. По сути, мы получаем распределённое хранение данных, обрабатываемых распределённым же образом — и всё это по цене расширения ОЗУ, удельная стоимость которого, к нашему большому счастью, в последнее время всё больше снижается. Идеологически грид-решения не имеют ограничений на объём ОЗУ кластера, так что проблемы роста объёма данных сверх неких граничных для технологии хранения объёмов с ними в значительной мере менее остры.

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

Тему In-Memory Data Grids мы обсудили с несколькими крайне интересными собеседниками. Интересными, помимо прочего, тем, что за плечами каждого из них стоят опыт и понимание того, как хорошо работающая система должна быть спроектирована и реализована. Итак, представляю:

Архитектура

GigaSpaces XAP построен из следующих подсистем:

Открытый интерфейсный слой

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

Core API

События

Space Based Remoting

Единые in-memory службы

В качестве платформы приложений GigaSpaces XAP обеспечивает интегрированные возможности выполнения на основе памяти.

Контейнер для эластичных приложений

XAP - это расширяемая масштабируемая среда исполнения с «эластичным развертыванием» для удовлетворения экстремальных требований к пропускной способности.

Линейная масштабируемость: Эластично развернуто / подготовлено, чтобы справляться с экстремальным спросом / пропускной способностью во время выполнения приложения без вмешательства человека
Гибкость: запуск различных типов модулей приложений, от простых веб-модулей до сложных модулей обработки событий
Упрощение перехода в производство:

*Гладкое, безрисковое развертывание путем идентичной разработки и производства окружающая среда *Более быстрое развертывание за счет исключения "силосов"(silos) *Непрерывное развертывание без простоя Легкие контейнеры приложений обеспечивают среду выполнения бизнес-логики на уровне узла. Они также переводят семантику и сервисы SBA в соответствующую реализацию инфраструктуры контейнерного развития. Например, space-транзакции переводятся на spring-ранзакции, когда используется легкий spring-контейнер. Контейнер Grid Service (GSC) отвечает за предоставление возможностей Grid, тогда как облегченная реализация контейнера отвечает на одном уровне VM. Эти архитектуры очень эффективны, поскольку позволяют приложениям использовать знакомые модели и сервисы программирования на одном уровне VM и, кроме того, предоставляют сетевые возможности и сервисы. GigaSpaces XAP предоставляет несколько реализаций по умолчанию в составе продукта и дополнительный API-интерфейс плагина для обеспечения интеграции других технологий. Архитектура показана на рисунке 1

Владимир Озеров (GridGain)

— У GridGain есть бесплатная и платные версии. Скажите, с технической точки зрения, разница между ними только в наличии техподдержки и нескольких функциях (таких, как WAN-репликация), а в остальном опенсорсный Apache Ignite и «платный» GridGain одинаковы? Или же мы имеем здесь дело с моделью «Fedora vs. RHEL», когда на бесплатном варианте проходят «боевую обкатку» фичи, которые в дальнейшем в более стабильном виде войдут в платную поставку?

Существует три версии продукта. GridGain Professional — это кодовая база Apache Ignite плюс поддержка и оперативное внесение правок и улучшений (хотфиксы). Это критически важный для бизнеса момент, так как в open source вам никто ничего не должен, и не с кого спросить.
Кроме Professional, мы предлагаем GridGain Enterprise и GridGain Ultimate — это продукты на основе GridGain Professional с расширенной функциональностью, таким как WAN-репликация, security, rolling upgrades, snapshots и т.д.

Хотфиксы сразу же попадают в master Apache Ignite, но релизятся раньше в рамках GridGain Professional. Поэтому платные пользователи получают их сразу, а бесплатные — либо ждут очередной релиз Apache Ignite, либо собирают его сами из мастера, на свой страх и риск.
Обкатку на бесплатных пользователях мы не практикуем :-)

— Судя по всему, Apache Ignite (или, если угодно, GridGain) позиционирует себя как более широкую по функциональности версию других систем IMDG. Это и правда причина для гордости или просто маркетинговый подход, чтобы выглядеть выгоднее на фоне других?

Отсюда видно, что мы действительно ушли далеко вперед от классического термина «IMDG». Тем не менее, Apache Ignite по-прежнему остается быстрым и удобным гридом, одно другому не мешает. Ну а кто «шире» или «уже» — решать пользователям :-)

— Проекты, которые требуют использования IMDG, практически всегда нестандартны, и решения, как архитектурные, так и технические, будут вырабатываться конкретно для проекта. На Ваш взгляд, должна ли компания, использующая в своих проектах Ignite/GridGain, обладать компетенциями на уровне технологического понимания устройства выбранного грид-решения? Необходим в штате компании специально выделенный IMDG DBA-специалист?

Очень правильный вопрос. Мы действительно сталкиваемся с дефицитом навыков применения и администрирования нашей системы, так как она слишком сильно отличается от классических СУБД, к которым все привыкли. Сейчас это во многом ложится на плечи наших solution architects. Но мы ведём многоплановую работу в данном направлении. Наш фокус — документация, тренинги и выстраивание партнерских отношений с компаниями-интеграторами. Всё это способствует распространению знаний и опыта. Думаю, в перспективе нескольких лет такие навыки станут достаточно массовыми.

Виктор Гамов (Confluent; ранее Hazelcast)

— Так уж повелось, что чуть ли не каждое IMDG-решение позиционирует себя как самое лучшее для пользователей (если не для всех, то для многих). Можно ли в такой теме однозначно говорить о лучшем/худшем?

Я бы говорил о use case, а не о понятии «лучший/худший». Нужно отталкиваться от моментов, связанных с внутренней архитектурой проекта. IMDG-решения развиваются каждое в своём направлении, и сравнивать их без ответа на вопрос «лучший для своего» — неверно.
Гриды, в отличие от решений для распределённых кэшей, умеет проводить вычисления непосредственно на своих нодах — это нишевая функциональность, но очень удобный для определённого рода задач. Однако порой IMDG используют только как кэш, и здесь, конечно, сложно проводить сравнения разных решений, поскольку задача не является целевой для гридов. Позже, кстати, разработчики чаще всего, разобравшись с гридом, начинают использовать и другие функции выбранной ими ранее IMDG.

В любом случае, о гридах нужно говорить с позиции разработчика, и исходить нужно, во-первых, из задачи, которую этот разработчик решает, а во-вторых, из его предыдущего опыта и используемого в проекте стека.

— На рынке много «чисто IMDG»-решений и практически лишь одно (Ignite/GridGain), которое себя позиционирует как нечто большее. Правильно ли говорить в такой ситуации, что для всех решений найдётся своя ниша, или можно сказать, что кто-то технологически ушёл вперед, а кто-то ещё не освоил дополнительные функции?

Я напомню фразу времен бурного роста Microsoft: «Давайте сконцентрируемся на всем!»
Думаю, наличие большого числа функций в изначально довольно нишевом продукте — это, во многом, вопрос маркетинга. Каждая IMDG чем-то интересна, и каждая находится в некоторой точке своего развития, так что темпы добавления функций везде разные.

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

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

— Долгое время концепция IMDG казалась оторванной от реальности: хранить все данные целиком в памяти было дорого и как-то нерационально, да и приложения работали через интерфейсы, оптимизированные под выборку и обработку аккуратно отобранной части данных. Сегодня IMDG всё чаще используют как некую «серебряную пулю». Можно ли ожидать, что эта технология будет на рынке достаточно долго, что это не очередное модное направление, которое однажды сменится другим?

Думаю, да. На мой взгляд, стоимость памяти будет падать, стоимость серверов также снижается, скорость связи по сети растёт — если ваша задача требует надёжного хранения больших объёмов данных с быстрым к ним доступом, использование IMDG будет ещё долгое время отличным выбором. Такого рода задачи будут всегда, поэтому гриды как инструмент будут востребованы.

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

Будет ли IMDG «серебряной пулей»? Вряд ли: это, как я уже говорил, нишевое решение, но востребованы гриды точно будут.

Обсуждать эту темe можно долго: спорить, соглашаться, холиварить и даже иногда бить в щи… И если первые три варианта можно реализовать в комментах, то за четвертым (хотя и первые три тоже можно будет практиковать) надо куда-то да ехать. Куда? Можно на Java-конференцию Joker 2017 (3-4 ноября, СПб) или на DevOps-конференцию DevOops 2017 (20 октября, СПб), — тут будет, с кем поговорить о хранилищах.

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

Итак, что же представляет из себя in-memory-data-grid?

Это кластерное key-value хранилище, которое предназначено для высоконагруженных проектов, имеющих большие объемы данных и повышенные требования к масштабируемости, скорости и надежности.
Основными частями IMDG являются кэши (в GemFire это называется регионами).
Кэш в IMDG — это распределенный ассоциативный массив (т.е. кэш реализует джавский интерфейс Map), обеспечивающий быстрый конкурентный доступ к данным с любого узла кластера.

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

Практически во всех IMDG кэши поддерживают транзакции.
Данные в кэшах хранятся в сериализованном виде (т.е. в виде массива байтов).

1. Скорость

Все данные находятся в оперативной памяти кластера, за счет чего существенно сокращается время доступа.
Т.к. все данные сериализованы, то время получения какого-либо объекта из кэша = (время перемещения объекта на конкретный узел кластера) + (время на десериализацию).
В случае, если запрашиваемый объект находится на том же узле, на котором выполнен запрос, то (время получения) = (время на десериализацию). И здесь мы видим, что доступ к данным мог бы быть вообще бесплатным, если бы объект не надо было десериализовать, для чего в концепцию IMDG было введено понятие near-cache.

Near-cache — это локальный кэш объектов для быстрого доступа, все объекты в нем хранятся готовыми к использованию. Если near-cache для данного кэша сконфигурирован, то объекты туда попадают автоматически при первом get-запросе этих объектов.

expiration — время жизни объекта в кэше
eviction — удаление объекта из кэша
ограничение по количеству хранимых объектов

2. Надежность

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

Т.е. если мы укажем, что потеря 2 узлов не должны привести к потере данных, то каждая партиция будет храниться на 3 разных узлах кластера, и при падении 2 узлов данные останутся неповрежденными. Если при этом в кластере осталось более одного узла, то опять будет создано 3 копии всех данных, и кластер будет готов к новым неприятностям.

3. Масштабируемость

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

4. Актуальность данных

При использовании IMDG вы всегда получаете актуальные данные, т.к. при выполнении put отсылается уведомление всем узлам кластера о том, что объекты с такими-то ключами получили новое значение. Каждый узел обновляет свои партиции, содержащие эти ключи, и удаляет старые значения из своего near-cache.

5. Снижение нагрузки на БД

IMDG можно использовать не только как самостоятельное хранилище, но и как узел системы, снимающий нагрузку с трудномасштабируемой реляционной БД.

во время запуска приложения высасывать все необходимые данные из БД в грид (так называемый preloading). Время подъема приложения увеличивается, потребление памяти тоже, но скорость работы растет
во время работы приложения подтягивать необходимые данные по запросам клиентов (read-through). Выполняется автоматически с помощью объекта Loader для данного кэша. Время подъема приложения небольшое, начальные затраты памяти тоже, но дополнительные временные затраты на обработку запросов, вызывающих read-through

при каждой операции put в кэш автоматически производится запись в БД с помощью Loader'a (так называемый write-behind). Подходит только для систем, основная нагрузка на которые вызывается чтением.
данные, ожидающие записи в БД, накапливаются, а потом производится один запрос на запись в БД. Сигналом к выполнению такого запроса может быть определенное количество данных, ожидающих записи, либо таймаут. Подходит для write-intensive систем, но сложнее в реализации

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

Вывод

In-memory-data-grid является сравнительно молодой, но хорошо себя зарекомендовавшей технологией, развитие которой ведется многими крупными вендорами. Она объединяет в себе достоинства NoSQL и систем кэширования, устраняет некоторые их существенные недостатки и позволяет поднять производительность системы на новый уровень. Если эта статья показалась вам интересной, то буду рад рассказать в следующий раз про какое-либо конкретное решение из семейства IMDG, а также затронуть вопросы построения и использования индексов, механизмов сериализации и взаимодействия с другими платформами в этих системах.

In-Memory Data Grid (IMDG) - это распределённое хранилище объектов, схожее по интерфейсу с обычной многопоточной хэш-таблицей, где хранятся объекты по ключам. IMDG предназначены для обеспечения высокой доступности и масштабируемости за счет распределения данных между несколькими компьютерами. Недавние достижения в 64-битных и многоядерных системах сделали возможным практическое хранение терабайтов данных полностью в ОЗУ, устраняя необходимость в электромеханических носителях данных, таких как жесткие диски. [Источник 1]

Особенности

Рисунок 1 - Концепция in-memory data grid

В отличие от традиционных систем, в которых ключи и значения ограничены типами данных «массив байт» и «строка», в IMDG можно использовать любой объект из бизнес-модели в качестве ключа или значения. Это значительно повышает гибкость, позволяя хранить в Data Grid в точности тот объект, с которым работает бизнес-логика, без дополнительной сериализации/де-сериализации, которую требуют альтернативные технологии.

Есть и другие функциональные особенности, которые отличают IMDG от других продуктов, таких как IMDB, NoSQL или NewSQL базы данных. Одна из основных — по-настоящему масштабируемое секционирование данных (Data Partitioning) в кластере. IMDG по сути представляет собой распределённую хэш-таблицу, где каждый ключ хранится на строго определённом сервере в кластере. Чем больше кластер, тем больше данных можно в нем хранить.

Ещё одной отличительной особенностью IMDG является поддержка транзакционности, удовлетворяющей требованиям ACID (atomicity, consistency, isolation, durability — атомарность, целостность, изоляция, сохранность). Как правило, чтобы гарантировать целостность данных в кластере, используют двухфазную фиксацию (2-phase-commit или 2PC). Разные IMDG могут иметь разные механизмы блокировок, но наиболее продвинутые реализации обычно используют параллельные блокировки (например, GridGain использует MVCC — multi-version concurrency control, управление конкурентным доступом с помощью многоверсионности), сводя тем самым сетевой обмен к минимуму, и гарантируя транзакционную целостность ACID с сохранением высокой производительности. [Источник 2]

По данным аналитической компании Gartner Inc., IMDG подходят для обработки больших данных «большой тройки»: скорости, изменчивости и объема. IMDG могут поддерживать сотни тысяч обновлений данных в памяти в секунду, их можно кластеризовать и масштабировать таким образом, чтобы поддерживать большие объемы данных. Конкретные преимущества технологии IMDG включают в себя:

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

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

Некоторые производители называют SSD, Flash-на-PCI, Storage Channel Storage и, конечно же, DRAM как «In-Memory». В действительности большинство поставщиков поддерживают модель многоуровневого хранения, в которой некоторая часть данных хранится в DRAM (самое быстрое хранилище, но с ограниченной емкостью), а затем переполняется на различные флэш-диски или дисковые устройства (медленнее, но с большей емкостью) - таким образом, это редко продукт DRAM-only или Flash-only. Тем не менее, важно отметить, что большинство продуктов в обеих категориях часто склоняются в основном к DRAM или к флеш-памяти на своей архитектуре.

Суть в том, что продукты сильно различаются в том, что они имеют в виду под «In-Memory», но в итоге все они имеют значительный компонент «In-Memory».

Содержание

Андрей Ершов (Dino Systems)

— Интересный технологический вопрос: выбор грид-решения на стадии проектирования системы. Что бы Вы посоветовали: сразу закладываться на широкий спектр фич, предлагаемых каким-то решением, либо идти по пути постепенного усложнения — запуститься на чём-то, что попроще, и, по мере роста проекта, исследовать возможность использования более функциональных решений?

Принципы работы всех IMDG похожи, но API может отличаться. Есть даже JSR-107, который унифицирует работу с IMDG, вне зависимости от вендора. В этом случае вы можете абсолютно безболезненно перейти от одного решения к другому. Но здесь есть несколько «но».
Во-первых, этот JSR описывает только базовые вещи, вроде «положить в кэш»/«прочитать из кэша», entry processors и continuous query. Зачастую такой функциональности может оказаться недостаточно, и тогда приходится использовать вендор-специфичные функции.

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

Опять же, переход на другое решение может подразумевать необходимость разбираться в настройках системы другого вендора.
Моя рекомендация — сразу выбрать вендора, но сначала использовать community версию, а потом заплатить за enterprise версию с техподдержкой и дополнительными фичами.

Скажу честно, выбор вендора — дело непростое, особенно, если вы первый раз имеете дело с IMDG и не до конца знаете сценарии использования IMDG в вашей системе. Хорошим подходом в данном случае будет создание PoC вашей системы с каждым из IMDG-решений.

У меня есть большой опыт работы только с GridGain (Ignite), также я имею представление о фичах Coherence и Hazelcast. Могу сказать, что все три решения предоставляют большую функциональность и имеют много общего. Если нужен key-value store с возможностью реагировать на изменения в grid, то можно смело брать любое решение. Но если вы планируете делать сложные запросы к данным, вам нужна поддержка транзакционности (с настраиваемым уровнем изоляции), сохранение данных на диск, репликация данных между дата-центрами, корректная работа в случае сетевой сегментации, сложное распределение данных по нодам, то имеет смысл изучить документацию каждого решения и выбрать подходящее для своей задачи.

— Если бы Вам в руки попала волшебная палочка, способная создать одну, но очень хорошую систему хранения данных — какую систему Вы бы заказали ей сделать?

Конечно, я как программист хочу, чтобы система была всегда доступна, вне зависимости от падения серверов и сетевых проблем, при этом чтобы она работала наиболее ожидаемым способом.

Вообще, когда речь заходит об ожиданиях о работе БД или IMDG, то говорят про consistency и freshness. Если система имеет дело с транзакциями, то ещё добавляется уровень изоляции транзакций (рекомендую к изучению доклад про CRDT на codefreeze; вот видео этого доклада — прим. автора). Чем выше уровень consistency и isolation, тем более предсказуемо ведёт себя система и тем проще её программировать. Самая лучшая гарантия — strict serializability (strong-1SR): это сочетание уровня изоляции транзакций serializability и уровня consistency — linearizability. Система, которая предоставляет strict serializability, и есть мечта.

Возможна ли такая система? Нас, конечно, будут интересовать распределённые системы. Тут мы вспомним CAP-теорему и скажем, что в случае CP (CA) такая система возможна и даже существует — Google Spanner. Однако, только Google может позволить себе такую систему — из-за очень высоких требований к инфраструктуре. И то приходится мириться с задержками на репликацию данных между континентами.

Хотелось бы иметь систему, которая гарантирует strict consistency в случае AP, то есть когда возможны сетевые проблемы, а также в случае, если нужно быстрое время отклика. Таких систем нет и быть не может, что показано, например, в PhD Peter Bailis.

Возвращаясь к теме выбора IMDG: задумайтесь, какие гарантии даёт то или иное решение, не нарушают ли рекламные обещания производителя теоретические ограничения распределённых систем? Можно ли положиться на IMDG, если у вас сгорел порт на свитче, или происходит длительная сборка мусора в JVM, или трактор разорвал кабель между вашими DC?

Читайте также: