wprowadzenie

istnieje dobrze znane twierdzenie Informatyczne zaproponowane przez Erica Brewera, które mówi, że dla bazy danych z rozproszonymi danymi można obiecać tylko dwie z następujących trzech cech:

• spójność
• dostępność
• tolerancja partycji

jest to bardzo abstrakcyjne, a terminologia nie jest do końca intuicyjna, więc w tym artykule dołożymy wszelkich starań, aby to złamać teoria od abstrakcyjnych do bardziej realnych rozmów i przykładów. To twierdzenie może sprawić, że pomyślisz o swojej architekturze bazy danych w kategoriach tego, czego naprawdę potrzebuje Twoja aplikacja i wyrzeczeń, które może być konieczne, aby je osiągnąć.

Definiowanie terminologii CAP

pozbądźmy się kilku podstawowych definicji, abyśmy mogli być na tej samej stronie, gdy będziemy mówić o tym twierdzeniu.

CAP – spójność, dostępność, tolerancja partycji

• spójność – wszystkie twoje serwery danych mają te same dane, więc możesz odpytywać dowolny serwer w systemie i uzyskać dokładnie te same dane.
• dostępność-każde zapytanie do serwerów danych otrzymuje odpowiedź. Jeśli jeden serwer jest zajęty, zostaje przekierowany na inny, który jest w stanie odpowiedzieć.
• tolerancja partycji-możliwość dalszego działania systemu, nawet jeśli występują awarie sieci i niektóre serwery nie mogą się komunikować.

podstawowe założenie – P jest niemożliwe

w rozproszonym systemie baz danych Twoje dane są dzielone na różne serwery i te serwery rozmawiają ze sobą przez sieć, dzięki czemu mogą zachować ten sam zestaw danych. Problem polega na tym, że sieci pękają i tak Zakładamy, że zawsze będzie się komunikować, czyli nie możemy mieć doskonałej sieci. W odniesieniu do tej teorii oznacza to, że w prawdziwym świecie trzeba poświęcić tolerancję podziału. Gdyby istniała doskonała, niezawodna sieć, nie mielibyśmy problemu z osiągnięciem spójności i dostępności, ale to jest prawdziwy świat zbudowany na fizycznych przewodach, które zawodzą, więc zakładamy, że się nie uda.

Jeśli P jest niemożliwe, jakie są nasze wybory?

ponieważ zrezygnowaliśmy z tolerancji partycji, twierdzenie mówi, że teraz musimy wybrać pomiędzy spójnością a dostępnością.

Możesz wybrać dostępność, w której Twoja aplikacja może zaspokoić wszystkie przychodzące żądania, ale nie może zagwarantować, że dane są najnowsze.

czego potrzebuje Twoja aplikacja?

Jeśli Twoja aplikacja jest portalem społecznościowym i nie musi mieć zawsze najnowszych danych, możesz wybrać dostępność. Czy to ważne, że użytkownicy widzą post po 30 sekundowym opóźnieniu? Jeśli nie, możesz preferować dostępność, ponieważ priorytetowo traktujesz to, aby użytkownicy mieli dostęp do danych, nawet jeśli nie są to najbardziej aktualne dane.

Jeśli z drugiej strony Twoja aplikacja wymaga, aby każdy odczyt do bazy danych był absolutną najnowszą danymi, będziesz musiał poświęcić dostępność i wybrać spójność. Niektóre żądania będą musiały się pomylić, ponieważ informacje nie są w stanie zagwarantować, że są absolutnie najnowsze.

wybory dokonywane przez relacyjne i NoSQL

technologie bazodanowe, takie jak SQL i inne relacyjne systemy bazodanowe zaprojektowane z myślą o spójności priorytetów ACID. Z drugiej strony większość baz danych NoSQL priorytetowo traktuje dostępność.

wniosek

uważamy, że zbadanie tego twierdzenia pod kątem aplikacji jest doskonałym ćwiczeniem i pomaga ocenić priorytety aplikacji. Jeśli masz rozproszony system danych, Sprawdź swoją architekturę i zrozum, jakie poświęcenie składasz.

MongoDB, CockroachDB i Postgres są dziś świetnymi technologiami bazodanowymi, które sprawiają, że nasze architektury baz danych są wyjątkowo solidne, ale jak już rozmawialiśmy, nie są idealne. Nie mamy doskonałej sieci i zawsze występuje „błąd użytkownika”. Jeśli przenosisz się do środowiska produkcyjnego i chcesz omówić najlepsze opcje dla swojej aplikacji, nie wahaj się skontaktować z nami pod adresem Object Rocket.