Twierdzenie CAP

menu icon

Twierdzenie CAP

W niniejszym przewodniku przyglądamy się twierdzeniu CAP oraz jego zastosowaniu podczas projektowania aplikacji rozproszonych i wybierania składnicy danych NoSQL lub relacyjnej składnicy danych.

Czym jest twierdzenie CAP?

Znasz reklamy ogrodników, malarzy lub innych rzemieślników, które zaczynają się od słów: „Tanio, szybko i dobrze: wybierz dwie opcje”?

Twierdzenie CAP stosuje podobny rodzaj logiki w systemach rozproszonych — zgodnie z nim system rozproszony może zapewnić tylko dwie z trzech pożądanych cech: spójność (consistency), dostępność (availability) oraz odporność na partycjonowanie (partition tolerance) („C”, „A” i „P” w skrócie CAP).

System rozproszony to sieć, która przechowuje dane w więcej niż jednym węźle (fizycznym lub w postaci maszyny wirtualnej) w tym samym czasie. Ponieważ wszystkie aplikacje w chmurze są systemami rozproszonymi, znajomość twierdzenia CAP jest niezbędna podczas projektowania aplikacji w chmurze, aby można było wybrać system zarządzania danymi mający charakterystykę najbardziej odpowiednią dla aplikacji.

Twierdzenie CAP jest nazywane również twierdzeniem Brewera, ponieważ po raz pierwszy zostało sformułowane przez profesora Erica A. Brewera podczas wykładu na temat przetwarzania rozproszonego w 2000 roku. Dwa lata później profesorowie MIT, Seth Gilbert i Nancy Lynch, opublikowali dowód na przypuszczenie Brewera.

Objaśnienie znaczenia skrótu CAP w twierdzeniu CAP

Przyjrzyjmy się szczegółowo trzem cechom systemów rozproszonych, do których odnosi się twierdzenie CAP.

Spójność

Spójność oznacza, że wszyscy klienci mają jednocześnie dostęp do tych samych danych, niezależnie od tego, z którym węzłem się łączą. Aby tak było, za każdym razem, gdy dane zostaną zapisane w jednym węźle, muszą zostać natychmiast przekazane lub zreplikowane do wszystkich pozostałych węzłów w systemie, zanim zapis zostanie uznany za zakończony pomyślnie.

Dostępność

Dostępność oznacza, że każdy klient wykonujący żądanie o dane otrzymuje odpowiedź nawet wtedy, gdy jeden lub większa liczba węzłów nie działa. Innymi słowy, wszystkie działające węzły w systemie rozproszonym zwracają poprawną odpowiedź dla każdego żądania, bez wyjątku.

Odporność na partycjonowanie

Partycja jest przerwą komunikacyjną w systemie rozproszonym — utraconym lub tymczasowo opóźnionym połączeniem między dwoma węzłami. Odporność na partycjonowanie oznacza, że klaster musi kontynuować działanie mimo dowolnej liczby przerw w komunikacji między węzłami w systemie.

Typy baz danych NoSQL w ujęciu twierdzenia CAP

Bazy danych NoSQL (nierelacyjne) idealnie sprawdzają się w przypadku rozproszonych aplikacji sieciowych. W przeciwieństwie do skalowalnych pionowo odpowiedników SQL (relacyjnych) bazy danych NoSQL są skalowalne poziomo i rozproszone z natury — można je szybko skalować w rosnącej sieci składającej się z wielu wzajemnie połączonych węzłów. (Więcej informacji na ten temat zawiera artykuł „SQL vs. NoSQL Databases: What's the Difference?”).

Obecnie bazy danych NoSQL są klasyfikowane w oparciu o dwie cechy CAP, którymi się charakteryzują:

  • Baza danych CP: baza danych CP zapewnia spójność i odporność na partycjonowanie kosztem dostępności. W przypadku partycji między dowolnymi dwoma węzłami, system musi zamknąć niespójny węzeł (tzn. uniemożliwić dostęp do niego), dopóki partycja nie zostanie usunięta.
  • Baza danych AP: baza danych AP zapewnia dostępność i odporność na partycjonowanie kosztem spójności. W przypadku partycji wszystkie węzły pozostają dostępne, ale te po niewłaściwej stronie partycji mogą zwracać starszą wersję danych niż inne. (Po usunięciu partycji bazy danych AP zazwyczaj resynchronizują węzły, aby naprawić wszystkie niespójności w systemie).
  • Baza danych CA: baza danych CA zapewnia spójność i dostępność wszystkich węzłów. Nie jest to jednak możliwe w przypadku partycji między dowolnymi dwoma węzłami w systemie. W takiej sytuacji nie może więc ona zapewnić odporności na błędy.

Ten typ wymieniliśmy na końcu nie bez przyczyny — w systemie rozproszonym nie da się uniknąć partycji. Możemy omówić rozproszoną bazę danych CA w teorii, ale z praktycznego punktu widzenia rozproszona baza danych CA nie może istnieć. Nie oznacza to jednak, że nie można zastosować bazy danych CA na potrzeby aplikacji rozproszonej, jeśli jest potrzebna. Wiele relacyjnych baz danych, np. PostgreSQL, zapewnia spójność i dostępność i można je wdrażać w wielu węzłach przy użyciu replikacji.

MongoDB a twierdzenie CAP (CP)

MongoDB jest popularnym systemem zarządzania bazami danych NoSQL, który przechowuje dane jako dokumenty BSON (binarny format JSON). Jest on często używany na potrzeby aplikacji czasu rzeczywistego i wielkich zbiorów danych działających w wielu różnych lokalizacjach. W ujęciu twierdzenia CAP MongoDB jest składnicą danych CP — usuwa partycje sieci przez zachowanie spójności kosztem dostępności.

MongoDB jest systemem z pojedynczym węzłem głównym — każdy zestaw replik (odsyłacz prowadzi poza serwis IBM) może mieć tylko jeden węzeł podstawowy, który otrzymuje wszystkie operacje zapisu. Wszystkie pozostałe węzły w tym samym zestawie replik są węzłami dodatkowymi, które replikują dziennik operacji węzła podstawowego i stosują go do własnego zestawu danych. Domyślnie klienty odczytują dane z węzła podstawowego, ale mogą też określić preferencję odczytu (odsyłacz prowadzi poza serwis IBM), która umożliwia im odczytywanie z węzłów dodatkowych.

Gdy węzeł podstawowy stanie się niedostępny, węzeł dodatkowy z najnowszym dziennikiem operacji zostanie wybrany jako nowy węzeł podstawowy. Gdy wszystkie pozostałe węzły dodatkowe zostaną zsynchronizowane z nowym węzłem głównym, klaster staje się ponownie dostępny. Ponieważ klienty nie mogą wykonywać żadnych żądań zapisu w tym czasie, dane pozostają spójne w całej sieci.

Cassandra a twierdzenie CAP (AP)

Apache Cassandra to baza danych NoSQL typu Open Source, a opiekunem tego projektu jest Apache Software Foundation. To szerokokolumnowa baza danych, która umożliwia przechowywanie danych w sieci rozproszonej. Jednak, w przeciwieństwie do MongoDB, Cassandra posiada architekturę, w której brak węzła głównego. W związku z tym ma wiele punktów awarii, a nie jeden.

W ujęciu twierdzenia CAP Cassandra jest bazą danych AP — zapewnia dostępność i odporność na partycjonowanie, ale nie może zagwarantować spójności przez cały czas. Ponieważ Cassandra nie ma węzła głównego, wszystkie węzły muszą być ciągle dostępne. Jednak Cassandra charakteryzuje się spójnością ostateczną — umożliwia klientom zapisywanie w dowolnym węźle w dowolnym momencie i uzgadnia niespójności tak szybko, jak to możliwe.

Ponieważ dane stają się niespójne tylko w przypadku partycji sieci, a niespójności są szybko usuwane, Cassandra oferuje funkcję naprawy (odsyłacz prowadzi poza serwis IBM), aby pomóc w aktualizowaniu węzłów. Dzięki stałej dostępności system ma bardzo wysoką wydajność, co w wielu przypadkach może być warte kompromisu.

Praca z mikrousługami

Mikrousługi to luźno powiązane komponenty aplikacji, które można wdrażać niezależnie oraz które mają własny stos — w tym własną bazę danych i model bazy danych — i komunikują się ze sobą za pośrednictwem sieci. Ponieważ mikrousługi można uruchamiać zarówno na serwerach w chmurze, jak i w lokalnych centrach przetwarzania danych, stały się one bardzo popularne w przypadku zastosowań w środowiskach hybrydowych i wielochmurowych.

Zrozumienie twierdzenia CAP może pomóc w wyborze najlepszej bazy danych podczas projektowania aplikacji opartej na mikrousługach, działającej w wielu lokalizacjach. Na przykład jeśli dla Twojej aplikacji kluczowa jest możliwość szybkiego iterowania modelu danych oraz skalowania w poziomie i akceptujesz spójność ostateczną (zamiast ścisłej), baza danych AP, taka jak Cassandra lub Apache CouchDB, może spełnić Twoje wymagania i uprościć wdrożenie. Z drugiej strony, jeśli Twoja aplikacja polega w dużej mierze na spójności danych — na przykład jest to aplikacja eCommerce lub obsługująca płatności — możesz wybrać relacyjną bazę danych taką jak PostgreSQL.

Twierdzenie CAP a IBM Cloud

IBM oferuje zakres w pełni zarządzanych usług dla baz danych. Oprócz systemów zarządzania relacyjnymi bazami danych na platformie IBM Cloud można również uruchamiać bazy danych MongoDB, Cloudant (inna rozproszona składnica danych AP), Elasticsearch, etcd i inne.

Aby zapoznać się z całą naszą ofertą baz danych (bez żadnych zobowiązań), zarejestruj się w celu uzyskania identyfikatora IBMid i utwórz konto na platformie IBM Cloud.