Architektura dla rozproszonego globalnie Neo4j?

Question

Robię trochę pracy dla organizacji, która ma biura w 48 krajach na całym świecie. Zasadniczo sposób, w jaki teraz pracują, polega na tym, że wszystkie przechowują dane w lokalnej kopii bazy danych i są one replikowane do wszystkich regionów/biur na świecie. Zdarza się, że muszą pracować bezpośrednio nad czymś, co "kopia deweloperska" znajduje się na serwerach w Londynie, i muszą łączyć się bezpośrednio z serwerami w Londynie, bez względu na to, gdzie się znajdują.

Więc powiedzmy, że chcę mieć pojedynczy wykres obejmujący całą organizację, która jest zaśmiecana, aby każdy region miał stosunkowo szybkie odczyty wykresu. Martwię się, że napisy zabiją wydajność. Rozumiem, że zapisy przechodzą przez jednego mistrza, czy oznacza to, że istnieje jeden mistrz na całym świecie? np. jeśli ten mistrz znajduje się w Londynie, to każdy zapis do bazy danych z Sydney musi przejść tę odległość niezależnie od lokalnego odłamka? A co by się stało, gdyby Sydney i Londyn zostały odcięte (z jakiegokolwiek powodu)?

Zasadniczo, w jaki sposób Neo4j rozwiązuje problem globalnej dystrybucji?

Answer 1

Mechanizm dystrybucji w edycji Neo4j Enterprise jest rzeczywiście w stylu master-slave. Każde żądanie zapisu do urządzenia master jest zatwierdzane lokalnie i synchronicznie przekazywane do numeru w slave zdefiniowanym przez push_factor (domyślnie: 1). Żądanie zapisu do urządzenia slave synchronicznie zastosuje go do wzorca, do niego samego i do wystarczającej liczby maszyn do spełnienia push_factor. Zsynchronizowana komunikacja typu "slave-to-master" może wpłynąć na wydajność, dlatego zaleca się wykonywanie przekierowań do systemu master i dystrybucję odczytów przez urządzenia podrzędne. Komunikacja w klastrze działa dobrze w sieciach o dużym opóźnieniu.

W konfiguracji z wieloma regionami zalecam posiadanie pełnego (co najmniej 3 wystąpień) klastra w "regionie pierwotnym". Kolejny klaster 3-instancji znajduje się w regionie wtórnym działającym w trybie tylko slave. W przypadku, gdy główny obszar ulega całkowitemu zejściu (dzieje się to bardzo rzadko, ale to się dzieje), narzędzie monitorujące wywołuje zmianę konfiguracji w regionie wtórnym, aby umożliwić jego instancjom stanie się wzorcem. Wszystkie inne biura wymagające szybkiego dostępu do odczytu mają wówczas x (x> = 1, w zależności od wydajności odczytu) instancji tylko slave. W każdej lokalizacji masz serwer proxy HA (lub inny LB), który kieruje zapis do mastera (zwykle w regionie głównym) i czyta do lokalnego regionu.

Jeśli chcesz przekroczyć ~ 20 wystąpień dla pojedynczego klastra, rozważ najpierw wykonanie poważnego proof of concept. Ze względu na architekturę master slave takie podejście nie jest skalowalne.