Architettura per un Neo4j distribuito globalmente?

Question

Sto lavorando per un'organizzazione che ha uffici in 48 paesi del mondo. Essenzialmente il modo in cui lavorano ora è che tutti memorizzano i dati in una copia locale del database e che vengono replicati in tutte le regioni/uffici nel mondo. Nella strana occasione in cui devono lavorare direttamente su qualcosa in cui la "copia di sviluppo" si trova sui server di Londra, devono connettersi direttamente ai server di Londra, indipendentemente da dove si trovino nel mondo.

Quindi, consente di dire che voglio avere un unico grafico che attraversa tutta l'organizzazione che è sharded in modo che ogni regione ha relativamente veloce legge del grafico. Sono preoccupato che le scritture stiano per uccidere le prestazioni. Capisco che le scritture passino attraverso un singolo master, vuol dire che esiste un unico master a livello mondiale? Ad esempio, se quel master si trova a Londra, allora ognuno di loro scrive nel database di Sydney deve attraversare quella distanza indipendentemente dal sharding locale? E cosa succederebbe se Sydney e Londra fossero tagliate fuori (per qualsiasi ragione)?

In sostanza, come si fa a risolvere il problema Neo4j distribuzione globale?

Answer 1

Il meccanismo di distribuzione in edizione Neo4j Enterprise è davvero stile master-slave. Qualsiasi richiesta di scrittura al master viene inoltrata localmente e trasferita in modo sincrono al numero in slave definito da push_factor (valore predefinito: 1). Una richiesta di scrittura a uno slave lo applicherà in modo sincrono al master, a se stesso e a un numero sufficiente di macchine per soddisfare push_factor. La comunicazione sincrona tra slave e master potrebbe influire sulle prestazioni, ecco perché si consiglia di eseguire il reindirizzamento delle scritture sul master e la distribuzione delle letture su slave. La comunicazione del cluster funziona bene su reti a latenza elevata.

In una configurazione multi-regione vi consiglio di avere un cluster completa (minimo aka 3 casi) nella 'regione di primaria'. Un altro cluster a 3 istanze si trova in una regione secondaria in esecuzione in modalità solo slave. Nel caso in cui la regione primaria vada giù completamente (accade molto raramente ma si piega) lo strumento di monitoraggio innesca una modifica di configurazione nella regione secondaria per consentire alle sue istanze di diventare master. Tutti gli altri uffici che richiedono un accesso veloce in lettura hanno quindi x (x> = 1, in base alle prestazioni di lettura) istanze solo slave. In ogni posizione si dispone di un proxy HA (o altro LB) che indirizza le scritture al master (normalmente nella regione principale) e legge nella regione locale.

Se si vuole andare al di là ~ 20 casi per un singolo cluster, in considerazione di fare una seria prova di concetto prima. A causa dell'architettura master slave questo approccio non viene scalato indefinitamente.