Architektur für einen global verteilten Neo4j?

Question

Ich mache etwas Arbeit für eine Organisation, die Büros in 48 Ländern der Welt hat. Im Wesentlichen arbeiten sie jetzt so, dass sie alle Daten in einer lokalen Kopie der Datenbank speichern und in alle Regionen/Büros der Welt repliziert werden. In den seltenen Fällen, in denen sie direkt an etwas arbeiten müssen, auf dem sich die "Entwicklungskopie" auf den Londoner Servern befindet, müssen sie sich direkt mit den Londoner Servern verbinden, unabhängig davon, wo sie sich auf der Welt befinden.

Also sagen wir, ich möchte ein einzelnes Diagramm haben, das die gesamte Organisation überspannt, die so geschichtet ist, dass jede Region relativ schnelle Lesevorgänge der Grafik hat. Ich mache mir Sorgen, dass die Schreibweise die Leistung zum Erliegen bringt. Ich verstehe, dass Schreibvorgänge einen einzelnen Master durchlaufen, bedeutet das, dass es global einen einzigen Master gibt? Wenn dieser Meister zufällig in London ist, muss jeder Schreibvorgang in der Datenbank von Sydney diese Entfernung durchqueren, unabhängig von der lokalen Gruppierung? Und was wäre, wenn Sydney und London (aus welchen Gründen auch immer) abgeschnitten würden?

Wie löst Neo4j im Wesentlichen das globale Verteilungsproblem?

Answer 1

Der Verteilungsmechanismus in Neo4j Enterprise Edition ist in der Tat Master-Slave-Stil. Jede Schreibanforderung an den Master wird lokal festgeschrieben und synchron an die Nummer in den unter push_factor definierten Slaves übertragen (Standard: 1). Eine Schreibanforderung an einen Slave wird synchron den Master, auf sich selbst und auf genügend Maschinen anwenden, um push_factor zu erfüllen. Die synchrone Kommunikation zwischen Slave und Master kann die Leistung beeinträchtigen, weshalb empfohlen wird, Schreibvorgänge auf den Master umzuleiten und Lesevorgänge über Slaves zu verteilen. Die Cluster-Kommunikation funktioniert gut in Netzwerken mit hoher Latenz.

In einem Multi-Region-Setup würde ich empfehlen, eine vollständige (aka mindestens 3 Instanzen) Cluster in der "primären Region" zu haben. Ein weiterer Cluster mit drei Instanzen befindet sich in einer sekundären Region, die im Nur-Slave-Modus ausgeführt wird. Falls die primäre Region vollständig abstürzt (passiert sehr selten, aber es ist nicht sichtbar), löst das Überwachungstool eine Konfigurationsänderung in der sekundären Region aus, um zu ermöglichen, dass seine Instanzen Master werden. Alle anderen Büros, die einen schnellen Lesezugriff benötigen, haben dann x (x> = 1, abhängig von der Leseleistung) Nur-Slave-Instanzen. An jedem Standort haben Sie einen HA-Proxy (oder einen anderen LB), der Schreibvorgänge an den Master (normalerweise in der primären Region) leitet und in die lokale Region liest.

Wenn Sie über ~ 20 Instanzen für einen einzelnen Cluster hinausgehen möchten, sollten Sie zuerst einen seriösen Machbarkeitsnachweis durchführen. Aufgrund der Master-Slave-Architektur ist dieser Ansatz nicht unbegrenzt skalierbar.