Twierdzenie CAP - dostępność i tolerancja podziału

Podczas gdy próbuję zrozumieć „dostępność” (A) i „tolerancję podziału” (P) w CAP, trudno mi było zrozumieć wyjaśnienia z różnych artykułów.

Mam wrażenie, że A i P mogą iść w parze (wiem, że tak nie jest i dlatego nie rozumiem!).

Wyjaśniając w prostych słowach, jakie są A i P i jaka jest między nimi różnica?

Spójność oznacza, że ​​dane są takie same w całym klastrze, więc możesz czytać lub zapisywać z / do dowolnego węzła i uzyskać te same dane.

Dostępność oznacza możliwość dostępu do klastra, nawet jeśli nastąpi awaria węzła w klastrze.

Tolerancja podziału oznacza, że ​​klaster nadal działa, nawet jeśli istnieje „podział” (przerwa w komunikacji) między dwoma węzłami (oba węzły są włączone, ale nie mogą się komunikować).

Aby uzyskać zarówno dostępność, jak i tolerancję partycji, musisz zrezygnować z spójności. Zastanów się, czy masz dwa węzły, X i Y, w konfiguracji master-master. Teraz jest przerwa między komunikacją sieciową między X i Y, więc nie mogą synchronizować aktualizacji. W tym momencie możesz:

A) Pozwól węzłom zsynchronizować się (rezygnując z spójności) lub

B) Rozważ klaster jako „wyłączony” (rezygnacja z dostępności)

Wszystkie dostępne kombinacje to:

• CA - dane są spójne między wszystkimi węzłami - o ile wszystkie węzły są w trybie online - i możesz czytać / zapisywać z dowolnego węzła i mieć pewność, że dane są takie same, ale jeśli kiedykolwiek opracujesz partycję między węzłami, dane będą brak synchronizacji (i nie zostanie ponownie zsynchronizowany po rozwiązaniu partycji).
• CP - dane są spójne między wszystkimi węzłami i zachowują tolerancję partycji (zapobiegając desynchronizacji danych), ponieważ stają się niedostępne, gdy nastąpi awaria węzła.
• Węzły AP pozostają w trybie online, nawet jeśli nie mogą się ze sobą komunikować i ponownie zsynchronizują dane po rozwiązaniu partycji, ale nie ma gwarancji, że wszystkie węzły będą miały te same dane (podczas lub po partycji)

Należy zauważyć, że systemy CA praktycznie nie istnieją (nawet jeśli niektóre systemy tak twierdzą).

Uznanie P w równych kategoriach z C i A jest trochę błędne, raczej pojęcie „2 z 3” wśród C, A, P wprowadza w błąd. Zwięźle wyjaśniłbym twierdzenie CAP: „W rozproszonym magazynie danych w czasie partycji sieciowej należy wybrać spójność lub dostępność i nie można uzyskać obu”. Nowsze systemy NoSQL starają się skupić na dostępności, podczas gdy tradycyjne bazy danych ACID bardziej koncentrują się na spójności.

Naprawdę nie możesz wybrać CA, partycja sieciowa nie jest czymś, co ktoś chciałby mieć, to po prostu niepożądana rzeczywistość systemu rozproszonego, sieci mogą zawieść. Pytanie brzmi, jaki kompromis wybierzesz dla swojej aplikacji, kiedy to nastąpi. Ten artykuł autorstwa człowieka, który sformułował ten termin, wydaje się wyjaśniać to bardzo wyraźnie.

Oto jak omawiam CAP, szczególnie w odniesieniu do P.

CA jest możliwe tylko wtedy, gdy jesteś zadowolony z monolitycznej bazy danych na jednym serwerze (być może z replikacją, ale wszystkie dane w jednym „bloku awarii” - serwery nie są uważane za częściowo uszkodzone).

Jeśli Twój problem wymaga skalowania, rozproszenia i obsługi wielu serwerów --- mogą wystąpić partycje sieciowe. Już wymagasz P. Kilka problemów, do których podchodzę, są podatne na paradygmaty zawsze z jednym serwerem (lub, jak powiedział Stonebraker, „rozproszone są stawki na stole”). Jeśli znajdziesz problem z urzędem certyfikacji, rozwiązania takie jak tradycyjny RDBMS bez skalowania zapewniają wiele korzyści.

Dla mnie rzadko: przechodzimy więc do dyskusji na temat AP przeciwko CP.

Możesz wybierać między działaniem AP i CP tylko wtedy, gdy masz partycję. Jeśli sieć i sprzęt działają poprawnie, dostajesz ciasto i jesz.

Omówmy rozróżnienie AP / CP.

AP - gdy istnieje partycja sieciowa, niech niezależne części działają swobodnie.

CP - gdy istnieje partycja sieciowa, zamykaj węzły lub nie zezwalaj na odczytywanie i zapisywanie, aby wystąpiły deterministyczne awarie.

Lubię architektury, które potrafią robić obie te rzeczy, ponieważ niektóre problemy to AP, a niektóre CP - a niektóre bazy danych mogą to robić. Wśród rozwiązań CP i AP są również subtelności.

Na przykład w zestawie danych AP masz możliwość zarówno niespójnych odczytów, jak i generowania konfliktów zapisu - są to dwa różne możliwe tryby AP. Czy twój system może być skonfigurowany do AP z wysoką dostępnością odczytu, ale nie zezwala na konflikty zapisu? A może twój system AP może zaakceptować konflikty zapisu przy użyciu silnego i elastycznego systemu rozwiązywania problemów? Czy w końcu będziesz potrzebować obu, czy może wybierzesz system, który tylko jeden?

W systemie CP, ile masz niedostępności z małymi partycjami (pojedynczy serwer), jeśli w ogóle? Większa replikacja może zwiększyć niedostępność w systemie CP, w jaki sposób system obsługuje te kompromisy?

To są wszystkie pytania, które należy zadać przy CP przeciwko AP.

Świetną lekturą w tej dziedzinie jest teraz post Browera „12 lat później”. Uważam, że to posuwa naprzód debatę na temat WPR z jasnością i bardzo ją polecam.

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

Konsystencja:

Odczyt gwarantuje zwrócenie ostatniego zapisu (np. ACID) dla danego klienta. Jeśli w tym czasie pojawi się jakieś żądanie, musi poczekać, aż synchronizacja danych zakończy się w / w węźle (węzłach).

Dostępność:

każdy węzeł (jeśli nie zawiedzie) zawsze wykonuje zapytania i zawsze powinien odpowiadać na żądania. Nie ma znaczenia, czy zwraca najnowszą kopię, czy nie.

Tolerancja podziału:

System będzie nadal działać po wystąpieniu partycji sieciowych.

Jeśli chodzi o AP , dostępność (zawsze dostępna) może istnieć z ( Cassendra ) lub bez tolerancji partycji ( RDBMS )

źródło obrazu

Wydaje mi się, że tolerancja podziału nie jest dobrze wyjaśniona w żadnej z odpowiedzi, więc wyjaśnienie rzeczy bardziej szczegółowo oznacza:

C : (Linearyzowalność lub silna konsystencja) z grubsza oznacza

Jeśli operacja B rozpoczęła się po pomyślnym zakończeniu operacji A, wówczas operacja B musi widzieć system w takim samym stanie, jak po zakończeniu operacji A lub w nowszym stanie (ale nigdy w starym stanie).

Odp . :

„Każde żądanie otrzymane przez niezawodny węzeł [bazy danych] w systemie musi skutkować odpowiedzią [bezbłędną]”. Nie wystarczy, aby jakiś węzeł mógł obsłużyć żądanie: każdy niezawodny węzeł musi być w stanie go obsłużyć. Wiele tak zwanych „wysoce dostępnych” (tj. O niskim przestoju) systemów faktycznie nie spełnia tej definicji dostępności.

P :

Tolerancja partycji (strasznie źle nazwana) w zasadzie oznacza, że ​​komunikujesz się przez sieć asynchroniczną, która może opóźniać lub upuszczać wiadomości. Internet i wszystkie nasze centra danych mają tę właściwość, więc tak naprawdę nie masz wyboru w tej sprawie.

Źródło: Awesome Martina kleppmann za pracę

Na przykład: Cassandra może być maksymalnie systemem AP. Ale jeśli skonfigurujesz go do odczytu lub zapisu w oparciu o kworum, nie będzie on dostępny w trybie CAP (dostępny zgodnie z definicją twierdzenia CAP) i jest tylko systemem P.

W prostym twierdzeniu CAP stwierdza, że ​​niemożliwe jest, aby system rozproszony jednocześnie zapewniał wszystkie trzy gwarancje:

Konsystencja

Każdy węzeł zawiera te same dane w tym samym czasie

Dostępność

Co najmniej jeden węzeł musi być dostępny do obsługi danych za każdym razem

Tolerancja podziału

Awaria systemu jest bardzo rzadka

Przeważnie każdy system może zagwarantować tylko dwie funkcje: CA, AP lub CP .

Spójność - gdy wysyłamy żądanie odczytu, jeśli zwraca wynik, powinno zwrócić ostatni zapis podany przez żądanie klienta. Dostępność - Twoje żądanie odczytu / zapisu zawsze powinno się powieść. Tolerancja partycji - gdy występuje partycja sieciowa (problem z niektórymi maszynami do komunikowania się ze sobą), system powinien nadal działać.

W rozproszonym są szanse, że nastąpi partycja sieciowa i nie możemy uniknąć „P” CAP. Wybieramy więc między „Spójnością” a „Dostępność”.

http://bigdatadose.com/understanding-cap-theorem/

Prosty sposób na zrozumienie twierdzenia CAP:

W przypadku partycji sieciowej należy wybrać między doskonałą dostępnością a idealną spójnością.

Spójność pobierania oznacza brak możliwości odpowiedzi na zapytanie klienta, ponieważ system nie może zagwarantować zwrócenia ostatniego zapisu. To poświęca dostępność.

Dostępność pobierania oznacza możliwość odpowiedzi na żądanie klienta, ale system nie może zagwarantować spójności, tj. Najnowszej zapisanej wartości. Dostępne systemy zapewniają najlepszą możliwą odpowiedź w danych okolicznościach.

To wyjaśnienie pochodzi z tego doskonałego artykułu . Mam nadzieję, że to pomoże.

Przeszedłem wiele linków, ale żaden z nich nie dał mi zadowalającej odpowiedzi, z wyjątkiem jednej.

Dlatego opisuję WPR bardzo prostymi sformułowaniami.

• Spójność : musi zwrócić te same dane , niezależnie od tego, z którego węzła pochodzi.

• Dostępność : Węzeł powinien odpowiedzieć (musi być dostępny).

• Tolerancja partycji : klaster powinien odpowiedzieć (musi być dostępny), nawet jeśli między węzłami istnieje partycja (tzn. Awaria sieci).

(Również jeden główny powód to dezorientuje więcej jest złe nazewnictwo niego Gdybym miał rację, może dałem. DNC twierdzenie zamiast: Dane Spójność , Dostępność Node , Cluster Dostępność , gdzie każda odpowiada Spójność , dostępność i podziału Tolerancja odpowiednio)

Baza danych CP: Baza danych CP zapewnia spójność i tolerancję partycji kosztem dostępności. Gdy partycja występuje między dwoma dowolnymi węzłami, system musi zamknąć niespójny węzeł (tzn. Uczynić go niedostępnym), dopóki partycja nie zostanie rozwiązana.

Baza danych AP: Baza danych AP zapewnia dostępność i tolerancję partycji kosztem spójności. Gdy nastąpi partycja, wszystkie węzły pozostają dostępne, ale te na niewłaściwym końcu partycji mogą zwrócić starszą wersję danych niż inne. (Po rozwiązaniu partycji bazy danych AP zwykle ponownie synchronizują węzły, aby naprawić wszystkie niespójności w systemie).

Baza danych CA: Baza danych CA zapewnia spójność i dostępność we wszystkich węzłach. Nie może tego zrobić, jeśli istnieje jakaś partycja między dwoma dowolnymi węzłami w systemie, a zatem nie może zapewnić odporności na uszkodzenia. W systemie rozproszonym nie można uniknąć partycji. Tak więc, chociaż teoretycznie możemy omówić rozproszoną bazę danych CA, dla wszystkich praktycznych celów rozproszona baza danych CA może istnieć, ale nie powinna istnieć.

Dlatego nie oznacza to, że nie możesz mieć bazy danych CA dla aplikacji rozproszonej, jeśli jej potrzebujesz. Wiele relacyjnych baz danych, takich jak PostgreSQL, zapewnia spójność i dostępność i można je wdrażać w wielu węzłach za pomocą replikacji.

Źródło: https://www.ibm.com/cloud/learn/cap-theorem