Artykuł w serii
Twierdzenie CAP mówi, że możesz wybrać dwa z trzech: Consistent, Available, Partition Tolerance. Tyle że rozproszone rozwiązania (a jak już dobrze wiemy, to wymóg miana NoSQL) ze względu na swoją naturę (działają na wielu maszynach) muszą być network partition tolerant, czyli działać mimo odrzucenia dowolnej liczby komunikatów między węzłami. W związku z tym mamy do wyboru jeszcze jedno z dwóch:
- consistent – każdy odczyt otrzymuje najnowszy zapis lub błąd,
- available – każde żądanie otrzymuje odpowiedź (bez błędu), bez gwarancji, że zawiera najnowszy zapis.
Nie znaczy to, że jest to binarny wybór. W obrębie jednego klastra część operacji może być consistent, a część available. Jest to zatem kompromis.
Można też balansować pomiędzy consistency a czasem odpowiedzi. Tym krócej będziemy czekać na odpowiedź, im mniej węzłów będzie musiało się ze sobą skomunikować (sprawdzając, gdzie jest najnowszy wpis). Odnosi się to również do sytuacji, kiedy wszystkie z nich działają. Ostatecznie sprowadza się to do decyzji biznesowej – chcemy odpowiadać szybko czy dokładnie? Amazon już dawno temu podjął tę decyzję, o czym pisałem tutaj w sekcji “Definiowanie wydajności”.
Problem ten w ogóle nie występuje w klasycznym podejściu do relacyjnej bazy danych, która działa na jednej maszynie. Odrzucamy wtedy partition tolerant (nie ma komunikacji pomiędzy węzłami) i zapytania będą zarówno consistent, jak i available.
Udostępnij ten wpis
Dobrnąłeś do końca. Jeśli ten artykuł był dla Ciebie wartościowy i chcesz otrzymywać informacje o kolejnych, to zapraszam Cię do zapisania się do listy mailingowej. Gwarantuję zero spamu.
Radek.
Inne artykuły
One thought on “Twierdzenie CAP, czyli kompromisy rozproszenia. [SQL vs NoSQL 5/6]”
Comments are closed.