Архитектура для глобально распределенного Neo4j?

Механизм распространения в редакции Neo4j Enterprise действительно является стилем master-slave. Любой запрос на запись к ведущему фиксируется локально и синхронно передается на количество ведомых устройств, определенное push_factor (по умолчанию: 1). Запрос на запись подчиненному устройству будет синхронно применяться к главному устройству, к самому себе и к достаточному количеству машин для выполнения push_factor. Синхронная связь между ведомым устройством и ведущим может снизить производительность, поэтому рекомендуется выполнять перенаправление записи на ведущее устройство и распределение операций чтения по ведомым устройствам. Кластерная связь отлично работает в сетях с высокой задержкой.

В конфигурации с несколькими регионами я бы рекомендовал иметь полный (минимум 3 экземпляра) кластер в «основном регионе». Еще один кластер с 3 экземплярами находится в дополнительном регионе, работающем только в подчиненном режиме. В случае, если первичный регион полностью выходит из строя (случается очень редко, но он отключается), инструмент мониторинга инициирует изменение конфигурации в вторичном регионе, чтобы его экземпляры стали главными. Все остальные офисы, которым требуется быстрый доступ для чтения, имеют x (x>=1, в зависимости от производительности чтения) экземпляров только для ведомых. В каждом месте у вас есть прокси-сервер HA (или другой LB), который направляет записи на главный сервер (обычно в основной регион) и читает в локальный регион.

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

По состоянию на 2020 год Neo4J по-прежнему является графовой базой данных только для репликации. У него есть некоторое количество основных серверов чтения-записи, которые существуют как часть его синхронизированного кластера, а затем некоторое количество реплик чтения-записи. Обновления выполняются на одном из основных серверов, а затем обновление синхронизируется на (N/2)+1 основных серверах до того, как клиент будет уведомлен об успешной фиксации. Это реализация Neo4J протокола RAFT. Все это означает, что Neo4J реализует репликацию и реплики распределяются. Все узлы и ребра графа могут находиться только на одном сервере.

Objectivity/DB реализует распределенную базу данных. Objectivity/DB позволяет пользователю распределять свой график по 65 000 серверов, где узел A может находиться на сервере 10, а узел B может находиться на сервере 47550, а граница между ними может находиться на сервере 543. Это позволяет одному подключенному графу выйти за пределы масштаба любого отдельного сервера. Интерфейс (API) к базе данных создает так называемое Единое логическое представление, где после подключения к федеративной базе данных клиент имеет Единое логическое представление всех данных во всей федерации, независимо от того, на каком хосте он находится. Это позволяет пользователю создавать массивные графики с использованием меньшего стандартного оборудования вместо того, чтобы покупать эксабайтный сервер для создания эксабайтного графика.

Другим преимуществом является то, что он позволяет пользователю размещать данные рядом с тем местом, где они будут использоваться. Если ваша организация распределена по всему миру, вы можете разместить данные по Гонконгу в Гонконге или рядом с ним, а данные по Нью-Йорку — в Нью-Йорке или рядом с ним. И вы можете создавать ребра между узлами в Гонконге и Нью-Йорке. И пользователь в Денвере может выполнять навигационные запросы по всему этому, потому что механизм запросов является распределенным.