In-Memory Data Grid (IMDG) и Hazelcast

Руководство по Hazelcast с Java - https://for-each.dev/lessons/b/-java-hazelcast

Hazelcast — это распределенная платформа In-Memory Data Grid для Java. Архитектура поддерживает высокую масштабируемость и распределение данных в кластерной среде. Он поддерживает автоматическое обнаружение узлов и интеллектуальную синхронизацию.

Что такое In-Memory Data Grid - https://habr.com/ru/articles/160517/

Задача In-Memory Data Grid (IMDG) — обеспечить сверхвысокую доступность данных посредством хранения их в оперативной памяти в распределённом состоянии.

Упрощенно, IMDG — это распределённое хранилище объектов, схожее по интерфейсу с обычной многопоточной хэш-таблицей. Вы храните объекты по ключам. Но, в отличие от традиционных систем, в которых ключи и значения ограничены типами данных «массив байт» и «строка», в IMDG Вы можете использовать любой объект из Вашей бизнес-модели в качестве ключа или значения. Это значительно повышет гибкость, позволяя Вам хранить в Data Grid в точности тот объект, с которым работает Ваша бизнес-логика, без дополнительной сериализации/де-сериализации, которую требуют альтернативные технологии. Это также упрощает использование Вашего Data Grid-а, поскольку в большинстве случаев Вы можете работать с распределённым хранилищем данных как с обычной хэш-таблицей. Возможность работать с объектами из бизнес-модели напрямую — одно из основных отличий IMDG от In-Memory баз данных (IMDB). В последнем случае пользователи всё ещё вынуждены осуществлять объектно-реляционное отображение (Object-To-Relational Mapping), которое, как правило, приводит к значительному снижению производительности.

https://dmitrybvita.blogspot.com/2025/01/blog-post_4.html - Хеш-таблица, массив и пр.

https://en.wikipedia.org/wiki/Distributed_data_store

Распределённое хранилище данных — это компьютерная сеть, в которой информация хранится более чем на одном узле, часто реплицируясь. ^[1] Обычно это понятие используется для обозначения либо распределённой базы данных, в которой пользователи хранят информацию на нескольких узлах, либо компьютерной сети, в которой пользователи хранят информацию на нескольких одноранговых узлах. ^[2]

https://ru.wikipedia.org/wiki/Репликация_(вычислительная_техника)

Репликация (англ. replication) — механизм синхронизации содержимого нескольких копий объекта (например, содержимого базы данных). Репликация — это процесс, под которым понимается копирование данных из одного источника на другой (или на множество других) и наоборот.

При репликации изменения, сделанные в одной копии объекта, могут быть распространены в другие копии.

https://en.wikipedia.org/wiki/Distributed_database

Распределённая база данных — это база данных, в которой данные хранятся в разных физических местах.^[1] Они могут храниться на нескольких компьютерах, расположенных в одном физическом месте (например, в центре обработки данных), или быть распределены по сети взаимосвязанных компьютеров. В отличие от параллельных систем, в которых процессоры тесно связаны и образуют единую систему баз данных, распределённая система баз данных состоит из слабо связанных узлов, не имеющих общих физических компонентов.

Системные администраторы могут распределять наборы данных (например, в базе данных) по нескольким физическим местоположениям. Распределённая база данных может находиться на организованных сетевых серверах или децентрализованных независимых компьютерах в Интернете, в корпоративных интранетах или экстранетах, а также в других сетях организаций. Поскольку распределённые базы данных хранят данные на нескольких компьютерах, распределённые базы данных могут повысить производительность на рабочих местах конечных пользователей, позволяя обрабатывать транзакции на многих компьютерах, а не только на одном.^[2]

Два процесса обеспечивают актуальность и современность распределённых баз данных: репликация^[3] и дублирование.

1. Репликация предполагает использование специализированного программного обеспечения, которое отслеживает изменения в распределённой базе данных. После обнаружения изменений процесс репликации приводит все базы данных к единому виду. Процесс репликации может быть сложным и трудоёмким, в зависимости от размера и количества распределённых баз данных. Этот процесс также может потребовать много времени и компьютерных ресурсов.
2. Дублирование, с другой стороны, менее сложное. Оно определяет одну базу данных как основную, а затем дублирует эту базу данных. Процесс дублирования обычно выполняется в установленное время в нерабочее время. Это делается для того, чтобы в каждом распределённом месте были одинаковые данные. В процессе дублирования пользователи могут изменять только основную базу данных. Это гарантирует, что локальные данные не будут перезаписаны.

https://habr.com/ru/companies/croc/articles/272795/ - Большой ликбез: распределённые системы хранения данных в практической привязке для админов среднего и крупного бизнеса

https://en.wikipedia.org/wiki/Hazelcast

В вычислительной технике, Hazelcast представляет собой унифицированную платформу данных в реальном времени^[3], реализованную на Java, которая сочетает в себе быстрое хранилище данных с потоковой обработкой. Это также название компании, которая разрабатывает продукт. 

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

Hazelcast может работать локально, в облаке (Amazon Web Services, Microsoft Azure, Cloud Foundry, OpenShift), виртуально (VMware) и в контейнерах Docker. Интерфейс поставщика услуг Hazelcast Cloud Discovery (SPI) позволяет облачным или локальным узлам автоматически находить друг друга.

Платформа Hazelcast может управлять памятью для многих типов приложений. Она предлагает открытый двоичный клиентский протокол для поддержки API для любого двоичного языка программирования. Участники сообщества Hazelcast и open-source создали клиентские API для языков программирования, которые включают Java, .NET, C ++, Python, Node.js и уходи.^[7]

HazelCast и синхронизация метода между несколькими нодами - https://habr.com/ru/companies/reksoft/articles/645997/

Что, если выкинуть все лишнее из базы в распределенный кэш – наш опыт использования Hazelcast - https://habr.com/ru/companies/yoomoney/articles/332462/

Обработка данных в реальном времени из API через Apache Kafka + Hazelcast - https://habr.com/ru/companies/otus/articles/741174/