Zookeeper /Chubby-vs-MySql NDB

Question

Zookeeper /Chubby-vs-MySql NDB

Czytałam artykuł Paxos, twierdzenie FLP itp. Ostatnio i oceniam Apache Zookeeper dla projektu. Ja też przechodziłem przez Chubby 'ego (usługę blokowania rozproszonego Google' a) i różną literaturę na ten temat, która jest dostępna w Internecie. Moim podstawowym zastosowaniem dla Zookeeper jest implementacja replikacji i ogólna koordynacja dla rozproszonego systemu.

Zastanawiałem się tylko, jaka jest szczególna zaleta, że Zookeeper lub pulchny jak rozproszony zamek system przynosi do stołu. W zasadzie zastanawiam się, dlaczego nie mogę po prostu użyć MySQL NDB Cluster. Ciągle słyszę, że MySQL ma wiele problemów z replikacją. Miałem nadzieję, że niektórzy z większym doświadczeniem w tym temacie rzucą na to trochę światła.

Z góry dzięki..

Uproszczona Lista moich wymagań:

mam jednorodny układ rozproszony.
potrzebuję jakiegoś sposobu na utrzymanie spójnego stanu we wszystkich moich węzłach.
mój system eksponuje a obsługa i interakcja z klientami doprowadzą do pewnej zmiany w zbiorowym stanie mojego systemu.
wysoka dostępność jest celem, więc węzeł spadający nie może mieć wpływu na usługę.
spodziewam się, że zbiorowy stan systemu będzie ograniczony wielkością (w zasadzie wstawianie/usuwanie będzie przejściowe... ale w stanie stacjonarnym oczekuję wielu aktualizacji i czytań)

15

mysql java apache-zookeeper replication database-replication

Author: arun_suresh, 2010-02-21

Source

2 answers

MySQL z Innodb zapewnia dobre rozwiązanie ogólnego przeznaczenia i prawdopodobnie nadąży za twoimi wymaganiami wydajnościowymi dość łatwo na niezbyt drogim sprzęcie. Może z łatwością obsługiwać wiele tysięcy aktualizacji na sekundę na podwójnym czterordzeniowym pudełku z przyzwoitymi dyskami. Wbudowana replikacja asynchroniczna zapewni Ci Większość możliwości spełniania wymagań dostępności , ale możesz stracić kilka sekund danych, jeśli podstawowa zawiedzie. Niektóre z tych utraconych danych mogą być odzyskiwanie po naprawie podstawowej lub może być odzyskiwalne z dzienników aplikacji: to, czy możesz to tolerować, zależy od działania systemu. Mniej stratną - ale wolniejszą-alternatywą jest użycie MySQL Innodb z dyskiem współdzielonym między jednostką podstawową i jednostką przełączania awaryjnego: w tym przypadku jednostka przełączania awaryjnego przejmie dysk, gdy podstawowa zawiedzie bez utraty danych - tak długo, jak podstawowa nie miała jakiejś katastrofy dysku. Jeśli udostępniony dysk nie jest dostępny, DRBD może być służy do symulacji tego poprzez synchronicznie kopiowanie bloków dyskowych do jednostki przełączania awaryjnego, gdy są zapisywane: może to mieć wpływ na wydajność.

Użycie Innodb i jednego z powyższych rozwiązań replikacji spowoduje skopiowanie danych do jednostki przełączania awaryjnego, co stanowi dużą część problemu z odzyskiwaniem, ale dodatkowy klej jest wymagany do ponownej konfiguracji systemu w celu uruchomienia jednostki przełączania awaryjnego. Jest to zwykle wykonywane z systemem klastrowym, takim jak RHCS lub rozrusznik serca lub bicie serca (na Linux) lub MS Cluster stuff Dla Windows. Systemy te są zestawami narzędzi i musisz ubrudzić sobie ręce, tworząc z nich rozwiązanie, które będzie pasowało do Twojego środowiska. Jednak w przypadku wszystkich tych systemów występuje krótki okres przestoju, podczas gdy system zauważa, że podstawowy nie powiódł się i rekonfiguruje system, aby używał jednostki przełączania awaryjnego. Może to potrwać dziesiątki sekund: próba zmniejszenia tego może sprawić, że system wykrywania awarii będzie zbyt wrażliwy i może okazać się, że system będzie nie udało się niepotrzebnie.

W górę, MySQL NDB ma skrócić czas odzyskiwania i w pewnym stopniu pomóc skalować bazę danych w celu poprawy wydajności. Jednak MySQL NDB ma dość wąski zakres zastosowania. System mapuje relacyjną bazę danych do rozproszonej tabeli hash, a więc w przypadku złożonych zapytań obejmujących wiele złączeń między tabelami istnieje spory ruch między komponentem MySQL a komponentami pamięci masowej (węzłami NDB), co sprawia, że złożone zapytania działają wolno. Jednak zapytania, które dobrze pasują, naprawdę działają bardzo szybko. Patrzyłem na ten produkt kilka razy, ale moje istniejące bazy danych były zbyt skomplikowane, aby dobrze pasowały i wymagałyby dużo przeprojektowania, aby uzyskać dobrą wydajność. Jednakże, jeśli jesteś na etapie projektowania nowego systemu, NDB będzie działać dobrze, jeśli możesz pamiętać o jego ograniczeniach na bieżąco. Ponadto, może się okazać, że potrzebujesz sporo maszyn, aby zapewnić dobre rozwiązanie NDB: kilka węzłów MySQL plus 3 lub więcej NDB nodes - chociaż węzły MySQL i NDB mogą współistnieć, jeśli twoje potrzeby wydajności nie są zbyt ekstremalne.

Nawet MySQL NDB nie radzi sobie z całkowitą utratą strony - pożar w centrum danych, błąd administratora itp. W takim przypadku zwykle potrzebny jest inny strumień replikacji biegnący do obiektu DR. Zwykle odbywa się to asynchronicznie, aby blipy łączności na łączu między witrynami nie zatrzymywały całej bazy danych. Jest to dostępne z opcją replikacji geograficznej NDB (w płatnej wersja telco), ale myślę, że MySQL 5.1 i wyżej może dostarczyć to natywnie.

Niestety, niewiele wiem o Zookeeper i Chubby. Mam nadzieję, że ktoś inny może podnieść te aspekty.

11

Author: Martin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-02-22 10:17:37

score 16 · Accepted Answer

Zależy to od rodzaju danych, którymi zarządzasz oraz skali i tolerancji błędów, na które dążysz.

Mogę odpowiedzieć z punktu widzenia Zookeepera. Przed rozpoczęciem powinienem wspomnieć, że ZooKeeper nie jest pulchnym klonem. W szczególności nie robi zamków bezpośrednio. Jest również zaprojektowany z myślą o różnych wymaganiach dotyczących zamawiania i wydajności.

W Zookeeperze cała kopia stanu systemu jest rezydentem pamięci. Zmiany są replikowane przy użyciu protokołu Atomic broadcast protocol i zsynchronizowane z dyskiem (za pomocą dziennika zmian) przez większość serwerów ZooKeeper przed przetworzeniem. Z tego powodu ZooKeeper ma deterministyczną wydajność, która może tolerować awarie tak długo, jak większość serwerów jest w górze. Nawet przy dużych przestojach, takich jak awaria zasilania, dopóki większość serwerów wróci na linię, stan systemu zostanie zachowany. Przechowywane informacje są zwykle uważane za podstawową prawdę systemu więc takie gwarancje spójności i trwałości są bardzo ważne.

Inne rzeczy, które daje ZooKeeper, mają związek z monitorowaniem dynamicznego stanu koordynacji. Efemeryczne węzły pozwalają na łatwe wykrywanie awarii i członkostwo w grupie. Gwarancje zamawiania pozwalają na wykonanie wyboru lidera i blokady po stronie klienta. Wreszcie, zegarki pozwalają monitorować stan systemu i szybko reagować na zmiany w stanie systemu.

Więc jeśli chcesz zarządzać i reagować na dynamiczną konfigurację, wykrywać awarie, wybierać liderów itp. ZooKeeper jest tym, czego szukasz. Jeśli potrzebujesz przechowywać dużo danych lub potrzebujesz modelu relacyjnego dla tych danych, MySQL jest znacznie lepszą opcją.