Zookeeper/Chubby -vs- MySql NDB

Question

Przeczytałem ostatnio gazetę Paxos, twierdzenie FLP itp. I dokonałem oceny Apache Zookeeper dla projektu. Przechodzę także przez Chubby (rozproszone usługi Google) i różne publikacje na ten temat dostępne online. Moim podstawowym zastosowaniem dla Zookeepera jest implementacja replikacji i ogólnej koordynacji dla systemu rozproszonego.

Zastanawiam się jednak, jaka jest szczególna zaleta, jaką Zookeeper lub system typu Chubby, jak rozproszone blokady, wprowadza do stołu. Zasadniczo zastanawiam się, dlaczego nie mogę po prostu użyć klastra NDB MySQL. Wciąż słyszę, że MySQL ma wiele problemów z replikacją. Miałem nadzieję, że niektórzy z większym doświadczeniem na ten temat mogą rzucić trochę światła na to.

góry dzięki ..

Uproszczony darmowa moich wymagań:

• mam jednorodnego systemu rozproszonego.
• Potrzebuję środków utrzymania spójnego stanu we wszystkich moich węzłach.
• Mój system udostępnia usługę, a interakcja z klientami prowadzi do pewnych zmian w zbiorowym stanie mojego systemu.
• Wysoka dostępność to cel, dlatego obniżenie węzła nie powinno mieć wpływu na usługę.
• Oczekuję, że system będzie obsługiwał co najmniej kilka 1000 req/s.
• Spodziewam zbiorowy stan systemu mają być ograniczone pod względem wielkości (po prostu wstawia/usuwa będzie przemijające ... ale w stanie stacjonarnym, spodziewam się wiele aktualizacji i czyta)

Answer 1

To zależy od rodzaju zarządzanych danych oraz od skali i tolerancji błędów, które zamierzasz wykonać.

Mogę odpowiedzieć z punktu ZooKeeper. Przed rozpoczęciem powinienem wspomnieć, że ZooKeeper nie jest klonem Chubby. W szczególności nie blokuje bezpośrednio. Jest również zaprojektowany z myślą o różnych wymogach dotyczących zamówień i wydajności.

W ZooKeeper cała kopia stanu systemu jest rezydentem pamięci. Zmiany są replikowane przy użyciu protokołu transmisji atomowej i synchronizowane z dyskiem (przy użyciu dziennika zmian) przez większość serwerów ZooKeeper przed przetworzeniem. Z tego powodu ZooKeeper ma deterministyczne działanie, które toleruje awarie, o ile większość serwerów jest gotowych. Nawet z dużą awarią, taką jak awaria zasilania, tak długo, jak większość serwerów wraca do sieci, stan systemu zostanie zachowany. Przechowywane informacje to ZooKeeper, który jest zwykle uważany 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 stanu dynamicznej koordynacji. Efemeryczne węzły pozwalają na łatwe wykrywanie awarii i członkostwo w grupach. Gwarancje zamówienia umożliwiają wykonanie wyborów lidera i zablokowanie po stronie klienta. Wreszcie zegarki pozwalają monitorować stan systemu i szybko reagować na zmiany w stanie systemu.

Więc jeśli potrzebujesz 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 lepszym rozwiązaniem.

Answer 2

MySQL z InnoDB zapewnia dobre, uniwersalne rozwiązanie, i prawdopodobnie będziesz nadążał za wymaganiami wydajnościowymi 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 porządnymi dyskami. Wbudowana asynchroniczna replikacja zapewni Ci większość możliwości związanych z dostępnością - ale możesz utracić kilka sekund danych w przypadku niepowodzenia podstawowego. Niektóre z tych utraconych danych mogą być odzyskane, gdy podstawowe jest naprawione lub można je odzyskać z dzienników aplikacji: to, czy możesz to tolerować, zależy od działania twojego systemu. Mniej stratną - ale wolniejszą - alternatywą jest użycie MySQL Innodb z dzielonym dyskiem pomiędzy jednostkami Primary i Failover: w tym przypadku jednostka Failover przejmie dysk, gdy Primary ulegnie awarii bez utraty danych - tak długo jak Primary nie miał żadnej katastrofy na dysku. Jeśli udostępniony dysk nie jest dostępny, DRBD może być użyty do symulacji tego poprzez synchroniczne kopiowanie bloków dysków do jednostki Failover, ponieważ są one zapisane: może to mieć wpływ na wydajność.

Korzystanie z Innodb i jednego z powyższych rozwiązań replikacji spowoduje, że dane zostaną skopiowane do urządzenia Failover, które stanowi znaczną część rozwiązanego problemu odzyskiwania, ale potrzebny jest dodatkowy klej do rekonfiguracji systemu w celu dostosowania urządzenia awaryjnego do trybu awaryjnego. linia. Zwykle jest to wykonywane w systemie klastrowym, takim jak RHCS lub Pacemaker lub Heartbeat (w systemie Linux) lub w MS Cluster dla systemu Windows. Te systemy to zestawy narzędziowe, a ty możesz zabrudzić sobie ręce, tworząc z nich rozwiązanie, które będzie pasować do twojego środowiska. Jednak w przypadku wszystkich tych systemów wystąpił krótki okres przestoju, podczas gdy system zauważy niepowodzenie systemu podstawowego i ponownie skonfiguruje system tak, aby korzystał z przełącznika awaryjnego. Może to być kilkadziesiąt sekund: próba zmniejszenia tego może spowodować, że twój system wykrywania błędów będzie zbyt czuły i może się okazać niepotrzebny niepotrzebny system.

Przesunięcie w górę, NDB MySQL ma na celu skrócenie czasu do odzyskania, a także w pewnym stopniu pomóc w skalowaniu bazy danych w celu zwiększenia wydajności. Jednak NDB MySQL ma dość wąski zakres zastosowania.System odwzorowuje relacyjną bazę danych na rozproszoną tablicę asocjacyjną, a więc w przypadku złożonych zapytań z wieloma połączeniami w różnych tabelach występuje duży ruch między komponentem MySQL a komponentami pamięci (węzłami NDB), co sprawia, że ​​złożone zapytania działają wolno. Jednak dobrze pasujące zapytania działają bardzo szybko. Kilka razy przyglądałem się temu produktowi, ale moje istniejące bazy danych były zbyt skomplikowane, by pasowały dobrze i wymagałyby wielu przeprojektowań, aby uzyskać dobrą wydajność. Jednakże, jeśli jesteś na etapie projektowania nowego systemu, NDB będzie działał dobrze, jeśli będziesz mógł znieść jego ograniczenia na uwadze. Ponadto, może się okazać, że potrzebujesz kilku maszyn, aby zapewnić dobre rozwiązanie NDB: kilka węzłów MySQL plus 3 lub więcej węzłów NDB - chociaż węzły MySQL i NDB mogą współistnieć, jeśli twoje potrzeby wydajnościowe nie są zbyt ekstremalne.

Nawet NDB MySQL nie poradzi sobie z całkowitą utratą danych - pożarem w centrum danych, błędem administratora itp. W takim przypadku zwykle potrzebny jest inny strumień replikacji, który zostanie uruchomiony na stronie DR. Zwykle będzie to wykonywane asynchronicznie, więc blipy łączności w łączu między lokacjami nie zatrzymają całej bazy danych. Jest on dostarczany z opcją replikacji geograficznej NDB (w płatnej wersji telco), ale myślę, że MySQL 5.1 i wyżej mogą to zapewnić natywnie.

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