Twierdzenie CAP: wyjaśnione

Uwaga: Ten post jest nieaktualny. Najbardziej aktualną wersję znajdziesz tutaj.

ten post jest nieaktualny. Zaktualizowaną wersję znajdziesz tutaj. Celowo zostawiam ten artykuł tutaj, aby nie zakłócać innych stron linkujących do mnie.

kilka lat temu budowanie wydajności w systemie oprogramowania było proste-albo zwiększyłeś zasoby sprzętowe (skaluj w górę), albo zmodyfikowałeś aplikację, aby działała wydajniej (dostrajanie wydajności). Obecnie istnieje trzecia opcja: skalowanie poziome (scale out).

horyzontalne skalowanie systemów oprogramowania stało się konieczne w ostatnich latach, ze względu na globalny charakter obliczeń i stale rosnące wymagania dotyczące wydajności aplikacji. W wielu przypadkach nie jest już dopuszczalne uruchamianie jednego serwera z jedną bazą danych w jednym centrum danych przylegającym do siedziby firmy. Potrzebujemy prawdziwie rozproszonych środowisk, aby sprostać dzisiejszym wyzwaniom biznesowym.

niestety korzyści z wydajności, jakie zapewnia skalowanie poziome, wiążą się ze złożonością kosztową. Systemy rozproszone wprowadzają do równania wydajności o wiele więcej czynników niż wcześniej. Rekordy danych różnią się w zależności od klientów/węzłów w różnych lokalizacjach. Pojedyncze punkty awarii niszczą czas działania systemu, a przerywane problemy z siecią pojawiają się w najgorszym możliwym czasie.

te obawy dotyczące spójności (C), dostępności (a) i tolerancji partycji (P) w systemach rozproszonych składają się na to, co ~~Eric Brewer~~ ukuty jako twierdzenie CAP. Mówiąc najprościej, twierdzenie CAP pokazuje, że każdy rozproszony system nie może zagwarantować jednocześnie C, A i P, a raczej kompromisy muszą być dokonywane w danym momencie, aby osiągnąć poziom wydajności i dostępności wymagany dla określonego zadania.

spójność – wszystkie węzły widzą te same dane w tym samym czasie.

Mówiąc najprościej, wykonanie operacji odczytu zwróci wartość ostatniej operacji zapisu, co spowoduje, że wszystkie węzły zwrócą te same dane. System ma spójność, jeśli transakcja rozpoczyna się od systemu w stanie spójnym i kończy się systemem w stanie spójnym. W tym modelu system może (i robi) przejście do niespójnego stanu podczas transakcji, ale cała transakcja zostanie wycofana, jeśli wystąpi błąd podczas dowolnego etapu procesu.

typowe relacyjne bazy danych są spójne: SQL Server, MySQL i PostgreSQL.

dostępność-każde zapytanie otrzymuje odpowiedź o sukcesie/porażce.

osiągnięcie dostępności w systemie rozproszonym wymaga, aby system działał przez 100% czasu. Każdy klient otrzymuje odpowiedź, niezależnie od stanu pojedynczego węzła w systemie. Ta metryka jest trywialna do zmierzenia: albo możesz wysyłać polecenia odczytu / zapisu,albo nie możesz.

dostępne są również typowe relacyjne bazy danych: SQL Server, MySQL i PostgreSQL. Oznacza to, że relacyjne bazy danych istnieją w przestrzeni CA – spójność i dostępność. CA jest jednak zarezerwowany nie tylko dla relacyjnych baz danych – niektóre narzędzia zorientowane na dokumenty, takie jak ElasticSearch, również należą do Ca.

tolerancja partycji-System nadal działa pomimo utraty wiadomości lub częściowej awarii.

większość ludzi uważa swój magazyn danych za pojedynczy węzeł w sieci. „This is our production SQL Server instance”. Każdy, kto prowadził instancję produkcyjną dłużej niż cztery minuty, szybko zdaje sobie sprawę, że tworzy to pojedynczy punkt awarii. System odporny na partycje może wytrzymać każdą awarię sieci, która nie spowoduje awarii całej sieci. Zapisy danych są wystarczająco replikowane w kombinacjach węzłów i sieci, aby utrzymać system przez przerywane przerwy w dostawie.

systemy pamięci masowej, które podlegają tolerancji partycji z spójnością (CP): MongoDB, Redis, AppFabric Caching i MemcacheDB. Systemy CP tworzą doskonałe rozproszone pamięci podręczne, ponieważ każdy klient otrzymuje te same dane, a system jest partycjonowany przez granice sieci.

systemy pamięci masowej, które podlegają tolerancji partycji z dostępnością (AP), obejmują DynamoDB, CouchDB i Cassandra.

przestarzały Framework CAP – nie używaj

wniosek

systemy rozproszone pozwalają nam osiągnąć poziom mocy obliczeniowej i dostępności, które były po prostu niedostępne w przeszłości. Nasze systemy mają wyższą wydajność, niższe opóźnienia i prawie 100% czasu sprawności w centrach danych na całym świecie. Co najlepsze, dzisiejsze systemy są uruchamiane na sprzęcie towarowym, który jest łatwo dostępny i konfigurowalny z kosztami zbliżającymi się do 0 USD.

cała ta moc obliczeniowa i korzyści mają jednak swoją cenę. Systemy rozproszone są bardziej złożone niż ich odpowiedniki oparte na jednej sieci. Istnieje o wiele więcej narzędzi i umiejętności, które należy nabyć, aby stworzyć naprawdę skalowalny, wysokowydajny system. Zrozumienie złożoności systemów rozproszonych, dokonanie odpowiednich kompromisów dla danego zadania (CAP) i wybór odpowiedniego narzędzia do pracy to kluczowe umiejętności w świecie, w którym systemy komputerowe się rozwijają, a nie w górę.



+