Twierdzenie CAP nie mówi po prostu: „wybierz dowolne dwie z trzech rzeczy”
CAP jest jednym z najczęściej upraszczanych twierdzeń w informatyce. Popularne hasło mówi, że system rozproszony wybiera dwie z trzech cech: consistency, availability i partition tolerance. Formalny wynik Gilberta i Lynch jest bardziej precyzyjny. Gdy dochodzi do partycji sieciowej, system nie może jednocześnie zagwarantować atomowej spójności oraz tego, że każde żądanie skierowane do nieuszkodzonego węzła otrzyma odpowiedź. Partycja nie jest więc zwykłą trzecią funkcją wybieraną z menu. To warunek awarii, w którym ujawnia się konflikt pomiędzy określonym rodzajem spójności i dostępnością.
Skąd wzięły się trzy litery
Consistency w formalizacji CAP odnosi się do bardzo silnej spójności odpowiadającej zachowaniu pojedynczej, atomowej kopii danych. Availability oznacza, że każde żądanie do działającego węzła kończy się odpowiedzią. Partition tolerance dotyczy sytuacji, w której komunikacja między częściami systemu może zostać przerwana, mimo że same maszyny nadal działają.
Najważniejsze słowa to „podczas partycji”
Jeżeli sieć działa poprawnie, dobrze zaprojektowany system może oferować zarówno spójne odpowiedzi, jak i wysoką dostępność. Dylemat CAP ujawnia się wtedy, gdy grupa węzłów nie może komunikować się z inną grupą. Jeśli obie strony nadal przyjmują dowolne operacje, mogą stworzyć sprzeczne stany. Jeśli system chce zachować jedną silnie spójną historię, część żądań musi poczekać lub zostać odrzucona.
Dlaczego „wybierz dwie” bywa mylące
Hasło sugeruje trwałą konfigurację produktu: baza A ma C+P, baza B A+P, a baza C C+A. Tymczasem praktyczne systemy podejmują bardziej złożone decyzje zależne od rodzaju operacji, topologii i aktualnej awarii. Partycje są czymś, z czym rozproszony system musi się liczyć; prawdziwe pytanie brzmi, jak zachowuje się wtedy wobec spójności i odpowiedzi.
Różne aplikacje mogą wybrać inaczej
System bankowy może w pewnym przypadku woleć odrzucić zapis niż zaakceptować dwie sprzeczne wersje salda. Inna usługa może uznać, że przyjęcie zamówienia jest ważniejsze i konflikt zostanie rozwiązany później. CAP nie podpowiada jednej najlepszej polityki. Pokazuje granicę: podczas odpowiedniej awarii nie da się zagwarantować wszystkiego naraz.
Twierdzenie jest ważne właśnie dlatego, że ogranicza marketing
Można optymalizować protokoły, zwiększać redundancję i budować lepsze sieci, ale nie da się stworzyć algorytmu, który usunie logiczny konflikt wynikający z braku komunikacji. CAP zmusza więc projektanta do zapisania, co system ma zrobić, gdy dwie strony przestają się widzieć. To znacznie bardziej użyteczne niż slogan o dwóch literach z trzech.
CAP mówi o gwarancjach, a nie o średnim zachowaniu
System może przez lata nie doświadczyć poważnej partycji i w normalnym działaniu wyglądać jak jednocześnie spójny i dostępny. Twierdzenie dotyczy tego, co może zagwarantować w dopuszczalnym scenariuszu awarii. To różnica podobna do algorytmów: „zwykle działa” nie jest tym samym co „dla każdego przypadku spełnia własność”. CAP jest więc narzędziem do analizy kontraktów systemu, nie benchmarkiem jego codziennej szybkości.
Późniejsze modele uzupełniają obraz
Nawet gdy nie ma partycji, rozproszone bazy podejmują kompromisy pomiędzy latencją i siłą spójności. Dlatego samo CAP nie opisuje wszystkich codziennych decyzji projektowych. W praktyce architekt pyta także o opóźnienie replikacji, quorum, regiony i oczekiwania klienta. Najzdrowsze użycie CAP polega na rozpoznaniu twardej granicy podczas partition, a nie na traktowaniu trzech liter jako pełnej teorii baz danych.
Ważne jest też, że słowo availability w formalnym CAP ma określone znaczenie i nie jest tym samym co marketingowe „99,99% uptime”. Chodzi o to, czy każde żądanie do nieuszkodzonego węzła w końcu dostanie odpowiedź, mimo partycji. System, który celowo odmawia części operacji, by zachować linearizability, rezygnuje z tej formalnej availability w scenariuszu partition. Może jednak w praktyce nadal mieć znakomitą dostępność mierzoną biznesowym SLA w normalnym roku.