Co wiesz o twierdzeniu CAP? Systemy rozproszone są dziś wszechobecne i zapewniają firmom większą elastyczność operacyjną. Ale jak one naprawdę działają i jakie są ograniczenia tego podejścia architektonicznego? Przeczytaj nasz artykuł, aby dowiedzieć się więcej.
Na rynku pojawiają się coraz to nowsze, bardziej zaawansowane rozwiązania dla biznesu. Są one bardziej złożone i pozwalają użytkownikom efektywniej udostępniać różnego rodzaju informacje lub pliki. Z pewnością zauważyłeś, że nowoczesne aplikacje są zazwyczaj oparte na sieci (potrzebujemy dostępu do sieci, aby z nich korzystać) i bardzo często działają globalnie. Potrzebują więc zaawansowanych rozwiązań, aby zapewnić niskie opóźnienia i spójność danych. Obecnie wiele produktów cyfrowych opiera się na systemach rozproszonych. Oczywiście żaden system rozproszony nie jest całkowicie bez wad. W przypadku tego rodzaju rozwiązań musimy zmierzyć się z różnymi wyzwaniami. Pozwól, że wyjaśnimy Ci twierdzenie CAP.
System tradycyjny – pojedyncza skrzynka
Twierdzenie CAP odnosi się do systemów rozproszonych, ale najpierw wyjaśnijmy, czym to podejście architektoniczne różni się od tradycyjnego. W systemie scentralizowanym istnieje jeden centralny serwer (zwany master), do którego podłączone są jeden lub więcej węzłów klienckich (slaves). Wykorzystuje architekturę klient-serwer, gdzie klienci wysyłają żądania do głównego serwera, a on odpowiada. Główną zaletą tego podejścia jest to, że jest bardzo łatwe w konfiguracji, zabezpieczeniu, aktualizacji i utrzymaniu (poprzez dodawanie lub usuwanie połączeń między master i slave). Największym ryzykiem jest niestabilność systemu i możliwość wystąpienia pojedynczego punktu awarii – każdy problem, który dotknie główny serwer, może spowodować wyłączenie całego systemu. Pionowe skalowanie (vertical scaling) jako jedyna opcja dodawania zasobów jest również ogromnym ograniczeniem. Dodanie większej skrzynki nie jest możliwe po przekroczeniu pewnego limitu – obciążenie może być po prostu zbyt duże, aby jedna maszyna mogła je obsłużyć.
Jeśli chodzi o przechowywanie danych, tradycyjny system jest najłatwiejszym sposobem na osiągnięcie zasad ACID (Atomicity, Consistency, Isolation, Durability) – koncepcji, na której zbudowane są relacyjne bazy danych. Pojęcie ACID oznacza "wszystko albo nic" – sekwencja operacji, która spełnia te zasady, nazywana jest transakcją, która z kolei traktowana jest jako pojedyncza jednostka – albo się powiedzie, albo całkowicie zawiedzie, nie ma nic pomiędzy. Posiadanie wszystkich danych w jednym miejscu (na serwerze master) gwarantuje, że baza danych pozostaje w harmonijnym stanie. Ten scentralizowany system żyje więc domyślnie w świecie spójności (consistency).
System rozproszony – nie ma szefaPo wejściu w erę szybkiego rozwoju Internetu nasze wymagania biznesowe drastycznie się zmieniły, a relacyjne bazy danych nie były już wystarczające dla potrzeb przechowywania złożonych systemów. Nie tylko spójność danych jest głównym problemem, ale dostępność (availability), wydajność (performance) i skalowalność (scalability) są teraz równie ważne. Najlepsi inżynierowie na naszej planecie musieli wymyślić sprytne rozwiązania, wśród których systemy rozproszone zyskały ogromną popularność (a twierdzenie CAP odnosi się konkretnie do rozproszonych magazynów danych). Opierają się one na idei, że nie ma już jednego szefa, który deleguje obowiązki swojemu zespołowi, ale każdy członek ma prawo podejmować decyzje. Technicznie, system rozproszony to zbiór niezależnych węzłów (nodes) umieszczonych w różnych lokalizacjach, które są połączone ze sobą i wymieniają informacje. Działa jako pojedyncza logiczna sieć danych i wydaje się użytkownikowi końcowemu, jakby był to jeden komputer, podczas gdy za kulisami cały stan systemu jest replikowany na wielu węzłach.
Niektóre z największych zalet systemu rozproszonego to:
- Skalowalność (Scalability) - możliwe jest wykorzystanie zarówno skalowania pionowego (vertical scaling), jak i poziomego (horizontal scaling) poprzez dodawanie zasobów obliczeniowych do każdego węzła lub dołączanie dodatkowych węzłów do sieci (to drugie jest prawie nieograniczone)
- Odporność na awarie (Fault tolerance) - w przypadku awarii jednego lub więcej węzłów, cały system pozostaje stabilny - działa - ponieważ zawsze dostępne są węzły, które mogą obsługiwać użytkowników
- Wydajność (Performance) - komponenty systemu współdzielą zasoby i działają współbieżnie, co umożliwia zrównoważenie całego obciążenia na wszystkich węzłach
Sprawy komplikują się, jeśli chodzi o przechowywanie danych. W systemie rozproszonym dość trudno jest osiągnąć konsensus. Podczas zapisywania nowych rekordów do bazy danych trzeba zdecydować, kiedy uznać to za zakończone – gdy dane utrwalą się na jednym węźle, czy dopiero po ich replikacji wszędzie. To przenosi nas do świata, w którym spójność (consistency) jest wyborem.
Twierdzenie CAP w Big Data
Twierdzenie CAP zostało stworzone w 2000 roku przez dr Erica Brewera. Odnosi się do systemów rozproszonych i stwierdza, że spośród spójności (consistency), dostępności (availability) i odporności na podział (partition tolerance) można osiągnąć tylko dwie z trzech (wszystkie trzy wymiary można w rzeczywistości wyobrazić sobie bardziej jako zakresy niż wartości boolowskie).
Skupmy się najpierw na odporności na podział (partition-tolerance). Odporność na podział w twierdzeniu CAP oznacza, że system będzie działał nawet wtedy, gdy wystąpi awaria sieci między dwoma lub więcej węzłami. Pamiętaj, że twierdzenie CAP odnosi się tylko do systemów rozproszonych, więc partycjonowanie jest koniecznością. Możemy więc zagwarantować albo dostępność i odporność na podział (system AP), albo spójność i odporność na podział (system CP), ale posiadanie zarówno spójności, jak i dostępności (CA) nigdy nie jest opcją.
Zasady projektowania systemów oparte na twierdzeniu CAP mówią, że jeśli przedkładamy dostępność nad spójność, każdy węzeł kontynuuje obsługę zapytań bez błędów, ale nie ma gwarancji, że odpowiedź zawiera najnowsze zapisy. W drugim przypadku każde żądanie otrzymuje najnowsze dane, ale może wystąpić błąd, jeśli utraci kontakt z innymi replikami, i ponosimy karę za opóźnienie (latency penalty).
Remedia spadają z nieba – zarządzanie danymi w chmurze
Czy problem bazy danych w twierdzeniu CAP można jakoś rozwiązać? Dostawcy chmur oferują różne nowoczesne rozwiązania do przechowywania danych, które pozwalają radzić sobie z kompromisami CAP, aby uzyskać korzyści z wysoce skalowalnych magazynów danych. Nie ma jednego magicznego rozwiązania, ponieważ wymiary optymalizacji bardzo się różnią. Możemy wybierać spośród zestawu usług, z których każda jest zoptymalizowana pod kątem konkretnego obciążenia. Przyjrzyjmy się kilku przykładom.
Google Cloud – Cloud Spanner – spójność
Spanner to globalna baza danych SQL oferowana w Google Cloud. Jest to technicznie system CP, co oznacza, że zawsze zapewnia spójność. Wykorzystuje TrueTime (funkcja wykorzystująca rozproszony zegar do przypisywania znaczników czasowych do transakcji), co pozwala użytkownikom na wykonywanie globalnie spójnych odczytów w całej bazie danych bez blokowania zapisów. Spanner twierdzi jednak również, że osiąga prawie 100% dostępność – dokładniej, lepiej niż "5 dziewiątek" (99,999%). Dlatego Spanner rozsądnie twierdzi, że jest w rzeczywistości systemem "efektywnie CA".
Amazon Web Services – Dynamo – dostępność
Dynamo to system przechowywania danych typu klucz-wartość o wysokiej dostępności, używany w Amazon Web Services, który został zaprojektowany, aby zapewnić "zawsze włączone" doświadczenie dla różnych ofert Amazon. Na przykład Amazon S3 (system przechowywania obiektów) opiera się na podstawowych funkcjach Dynamo, aby sprostać potrzebom skalowania i wymaganiom dotyczącym niezawodności. Dostępność można tu osiągnąć poprzez poświęcenie spójności (poprzez tzw. "model spójności ostatecznej" – wszystkie aktualizacje docierają do wszystkich replik ostatecznie w pewnym momencie w przyszłości).
Microsoft Azure – Cosmos DB – wybierz sam
Cosmos DB to globalnie rozproszona baza danych NoSQL oferowana w chmurze Azure przez Microsoft. Użytkownicy mogą wybrać jeden z pięciu predefiniowanych modeli spójności – każdy z nich daje różne wskaźniki dla pól CAP. Wybory to: Strong (przedkłada spójność danych ponad wszystko inne), Bounded-stateless, Session, Consistent prefix i Eventual (tutaj dostępność jest zwycięzcą). Te opcje zmieniają dylemat z wyboru typu "0-1" w szerokie spektrum możliwości dostosowanych do potrzeb klientów.
Jeśli Twoja firma szuka nowoczesnego rozwiązania do przechowywania danych, które zapewni wszystkim użytkownikom szybkie i responsywne doświadczenie, nie wahaj się z nami skontaktować. Pomożemy Ci sprostać wyzwaniom związanym z zarządzaniem danymi i w pełni wykorzystać Twój system.
Przeprojektowany interfejs uzytkownika w airflow-2-0
Wprowadzenie do jakosci danych definicje i przyklady
Przyszłość inżynierii danych - trendy do obserwacji w 2025 roku
