BASE to model spójności charakterystyczny dla wielu baz NoSQL, w którym świadomie rezygnujesz z natychmiastowej spójności danych na rzecz dostępności i odporności na obciążenie. Skrót rozwija się jako Basically Available, Soft state, Eventual consistency — czyli: system jest praktycznie zawsze dostępny, jego stan może być chwilowo „rozjechany” między węzłami, a spójność osiąga w końcu (po jakimś czasie), zamiast w tej samej milisekundzie. To filozoficzne przeciwieństwo ACID, znanego z relacyjnych baz danych, gdzie transakcja albo wykonuje się w całości i natychmiast widoczna jest spójna, albo nie wykonuje się wcale.
Sama nazwa to inżynierski żart: chemicznie acid (kwas) i base (zasada) to przeciwieństwa, a autorzy z grupy Erica Brewera dorobili do tego pasujący akronim. Brewer jest też autorem twierdzenia CAP, które mówi, że w systemie rozproszonym przy podziale sieci (partition) musisz wybrać między spójnością a dostępnością. BASE to po prostu konsekwentny wybór dostępności.
Jak to działa w praktyce
Wyobraź sobie, że masz dane rozrzucone na kilkudziesięciu serwerach w różnych regionach. Gdy zapisujesz coś na jednym węźle, zmiana nie musi być od razu potwierdzona przez wszystkie repliki. Zapis „przechodzi”, a synchronizacja dzieje się w tle. Przez moment różne węzły mogą zwrócić różne wartości tego samego klucza — i to jest akceptowane (eventual consistency: jeśli przestaniesz pisać, po chwili wszystkie repliki się zgodzą).
Dzięki temu system trzyma niski czas odpowiedzi i działa nawet, gdy część węzłów padnie albo sieć się rozjedzie. Płacisz za to ryzykiem, że odczyt zwróci nieaktualne dane.
Konkretny przykład
Klasyk to Amazon DynamoDB albo Apache Cassandra. W DynamoDB domyślnie dostajesz eventually consistent reads — szybsze i tańsze. Jeśli akurat potrzebujesz świeżych danych, prosisz o silniejszą gwarancję, np. w AWS CLI:
aws dynamodb get-item --table-name Koszyki --key '{"id":{"S":"42"}}' --consistent-read
Flaga --consistent-read wymusza odczyt spójny (kosztem wydajności). Brak flagi = BASE w czystej postaci: szybko, tanio, ale możesz trafić na dane sprzed sekundy.
Częste błędy i mity
- „NoSQL = brak spójności na zawsze” — nie. Eventual consistency znaczy w końcu, nie nigdy. Większość baz BASE pozwala też na silniejsze tryby, gdy ich potrzebujesz.
- Liczenie pieniędzy na BASE. Saldo konta, stany magazynowe, rezerwacje miejsc — tu chwilowa rozbieżność potrafi zaboleć. Do takich rzeczy wybieraj ACID albo świadomie projektuj mechanizmy reconciliacji.
- Mit, że ACID i BASE to wybór religijny. Nowoczesne systemy mieszają jedno z drugim per operacja — to decyzja inżynierska, nie tożsamościowa.
Pojęcia powiązane: ACID, twierdzenie CAP, eventual consistency, NoSQL, replikacja, sharding, DynamoDB, Cassandra, quorum.