Ostateczna spójność w prostym języku angielskim

130

Często słyszę o ostatecznej spójności w różnych wypowiedziach na temat NoSQL, siatek danych itp. Wydaje się, że definicja ostatecznej spójności różni się w wielu źródłach (a może nawet zależy od konkretnego przechowywania danych).

Czy ktoś może w prosty sposób wyjaśnić, czym jest ostateczna spójność w ujęciu ogólnym, niezwiązanym z żadnym konkretnym przechowywaniem danych?

rzymski
źródło
1
Czy np. Wikipedia nie pomogła? en.wikipedia.org/wiki/Eventual_consistency
Oliver Charlesworth
21
@OliCharlesworth: nie. Może to tylko ja, ale jest to absolutnie niejasne nawet po dwukrotnym przeczytaniu.
Roman

Odpowiedzi:

228

Ostateczna spójność:

  1. Oglądam prognozę pogody i dowiaduję się, że jutro będzie padać.
  2. Mówię ci, że jutro będzie padać.
  3. Twój sąsiad mówi żonie, że jutro będzie słonecznie.
  4. Powiedz sąsiadowi, że jutro będzie padać.

W końcu wszyscy kelnerzy (ty, ja, twój sąsiad) znają prawdę (że jutro będzie padać), ale w międzyczasie klient (jego żona) wyszedł, myśląc, że będzie słonecznie, mimo że zapytała po tym, jak jeden lub więcej serwerów (ty i ja) miał bardziej aktualną wartość.

W przeciwieństwie do ścisłej spójności / zgodności z ACID:

  1. Twoje saldo bankowe wynosi 50 USD.
  2. Wpłacasz 100 $.
  3. Twoje saldo bankowe, sprawdzone z dowolnego bankomatu, wynosi 150 USD.
  4. Twoja córka wypłaca 40 $ za pomocą Twojej karty bankomatowej.
  5. Twoje saldo bankowe, sprawdzone z dowolnego bankomatu, wynosi 110 USD.

W żadnym momencie saldo nie może odzwierciedlać niczego innego niż faktyczna suma wszystkich transakcji dokonanych na koncie do tego dokładnego momentu.

Powód, dlaczego tak wiele systemów NoSQL mieć ewentualne spójności jest to, że praktycznie wszystkie z nich są przeznaczone do dystrybucji, a także z systemami w pełni rozproszonych jest na górze super-liniowy do utrzymywania ścisłej spójności (czyli można skalować tylko tak daleko, zanim wszystko zaczyna zwalniać w dół, a kiedy to zrobią, musisz rzucić wykładniczo więcej sprzętu na problem, aby utrzymać skalowanie).

Chris Shain
źródło
Nie rozumiem. Czy wzrost jest liniowy czy wykładniczy?
Maciek Kreft
4
Wzrost narzutu komunikacyjnego systemu N ściśle spójnych węzłów jest ogólnie rozumiany jako nadliniowy (to znaczy bardziej niż liniowy). Może być wykładniczy, może być sześcienny ... Zależy od protokołu komunikacyjnego itp.
Chris Shain,
2
Dobra odpowiedź. Kilka dodatkowych pytań: czyż nie jest "złe", że żądania wysyłane do serwera mogą powodować otrzymanie błędnych / nieaktualnych informacji? Czy ludzie po prostu się z tym zgadzają, czy jest na to rozwiązanie? Ponadto, w jaki sposób dane są ostatecznie replikowane na różnych serwerach? Jeśli jeden z serwerów uległ awarii, a dane są replikowane między serwerami, jeśli ten serwer wróci do normy, w jaki sposób może zaktualizować swoje dane?
noblerare
5
@noblerare to „złe” z powodu różnego stopnia zła. Byłoby bardzo źle, gdyby moje saldo w bankomacie było nieaktualne. Jest mniej źle, jeśli moja baza danych logowania nie jest do końca złapana lub jeśli mój kanał na Facebooku jest kilka sekund opóźniony. Mechanizmy replikacji i trwałości danych są bardzo zróżnicowane i zależą od konkretnej platformy. Dla Cassandry (na przykład) autor może zdecydować, czy aby dany zapis był udany, musi zostać zatwierdzony na jednym, wszystkich lub kworum (większości) węzłów. HBase przyjmuje inne podejście, w którym określony węzeł jest „głównym” dla każdego wiersza danych.
Chris Shain,
W rzeczywistości większość systemów bankowych jest ostatecznie spójna.
Chaos
106

Ostateczna spójność:

  1. Twoje dane są replikowane na wielu serwerach
  2. Twoi klienci mogą uzyskać dostęp do dowolnego serwera w celu pobrania danych
  3. Ktoś zapisuje dane na jednym z serwerów, ale nie zostały one jeszcze skopiowane na pozostałe
  4. Klient uzyskuje dostęp do serwera z danymi i otrzymuje najbardziej aktualną kopię
  5. Inny klient (lub nawet ten sam klient) uzyskuje dostęp do innego serwera (takiego, który nie otrzymał jeszcze nowej kopii) i otrzymuje starą kopię

Zasadniczo, ponieważ replikacja danych na wielu serwerach zajmuje trochę czasu, żądania odczytu danych mogą trafiać na serwer z nową kopią, a następnie na serwer ze starą kopią. Termin „ewentualne” oznacza, że ​​ostatecznie dane będą replikowane na wszystkie serwery, a zatem wszystkie będą miały aktualną kopię.

Ostateczna spójność jest koniecznością, jeśli chcesz odczytywać z niewielkimi opóźnieniami, ponieważ serwer odpowiadający musi zwrócić własną kopię danych i nie ma czasu na konsultowanie się z innymi serwerami i osiągnięcie wzajemnego porozumienia w sprawie zawartości danych. Napisałem post na blogu, wyjaśniając to bardziej szczegółowo.

Ezra Hoch
źródło
2
Niezły post na blogu. Warto przeczytać dla kogoś nowego w idei ostatecznej spójności. Ta odpowiedź byłaby lepsza, gdyby została przepisana, aby wyjaśnić więcej tego, co jest w poście na blogu.
axiopisty
1
Dobrze wyjaśnione na Twoim blogu. Dzięki za udostępnienie.
Ataur Rahman Munna
12

Myślisz, że masz aplikację i jej replikę. Następnie musisz dodać nową pozycję danych do aplikacji.

wprowadź opis obrazu tutaj

Następnie aplikacja synchronizuje dane z inną repliką pokazaną poniżej

wprowadź opis obrazu tutaj

W międzyczasie nowy klient otrzyma dane z jednej repliki, która nie jest jeszcze aktualizowana. W takim przypadku nie może uzyskać poprawnych aktualnych danych. Ponieważ synchronizacja zajmuje trochę czasu. W takim przypadku ostatecznie nie jest to spójne

Problem w tym, jak możemy ostatecznie osiągnąć spójność ?

W tym celu używamy aplikacji mediatora do aktualizacji / tworzenia / usuwania danych i używamy bezpośredniego zapytania do odczytu danych. które pomagają ostatecznie uzyskać spójność

wprowadź opis obrazu tutaj wprowadź opis obrazu tutaj

wthamira
źródło
3

Kiedy aplikacja dokonuje zmiany w elemencie danych na jednym komputerze, zmiana ta musi zostać propagowana do innych replik. Ponieważ propagacja zmiany nie jest natychmiastowa, istnieje przedział czasu, w którym niektóre kopie będą miały ostatnią zmianę, a inne nie. Innymi słowy, kopie będą wzajemnie niespójne. Jednak ostatecznie zmiana zostanie rozpowszechniona we wszystkich kopiach, stąd termin „ostateczna spójność”. Termin ostateczna spójność jest po prostu potwierdzeniem, że istnieje nieograniczone opóźnienie w propagowaniu zmiany dokonanej na jednym komputerze do wszystkich pozostałych kopii. Ostateczna spójność nie jest znacząca ani istotna w systemach scentralizowanych (pojedyncza kopia), ponieważ nie ma potrzeby propagowania.

źródło: http://www.oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf

Alice
źródło
1

Prostym językiem angielskim możemy powiedzieć: Chociaż twój system może znajdować się w niespójnych stanach, celem jest zawsze osiągnięcie spójności w pewnym momencie dla każdego elementu danych.

Alireza Rahmani Khalili
źródło
1

Ostatecznie spójność oznacza, że ​​propagacja zmian wymaga czasu, a dane mogą nie być w tym samym stanie po każdym działaniu, nawet w przypadku identycznych działań lub transformacji danych. Może to spowodować bardzo złe rzeczy, gdy ludzie nie wiedzą, co robią podczas interakcji z takim systemem.

Nie wdrażaj magazynów danych dokumentów o znaczeniu krytycznym, dopóki dobrze nie zrozumiesz tej koncepcji. Zepsucie implementacji magazynu danych dokumentu jest znacznie trudniejsze do naprawienia niż model relacyjny, ponieważ podstawowych rzeczy, które mają zostać schrzanione, po prostu nie można naprawić, ponieważ rzeczy, które są wymagane, aby to naprawić, po prostu nie występują w ekosystemie. Refaktoryzacja danych magazynu pokładowego jest również znacznie trudniejsza niż proste przekształcenia ETL w RDBMS.

Nie wszystkie magazyny dokumentów są takie same. Niektóre obecnie (MongoDB) obsługują pewnego rodzaju transakcje, ale migracja magazynów danych jest prawdopodobnie porównywalna z kosztem ponownej implementacji.

OSTRZEŻENIE: Programiści, a nawet architekci, którzy nie znają lub nie rozumieją technologii przechowywania danych dokumentów i boją się przyznać, że z obawy przed utratą pracy, ale zostali klasycznie przeszkoleni w zakresie RDBMS i znają tylko systemy ACID (jak bardzo może to być ?), a kto nie zna technologii lub nie ma czasu, aby się jej nauczyć, będzie tęsknił za zaprojektowaniem magazynu danych dokumentów. Mogą również spróbować użyć go jako RDBMS lub do rzeczy takich jak buforowanie. Rozbiją to, co powinno być atomowymi transakcjami, które powinny operować na całym dokumencie, na „relacyjne” części, zapominając, że replikacja i opóźnienie to rzeczy, lub, co gorsza, wciągając systemy stron trzecich w „transakcję”. Zrobią to, aby ich RDBMS mógł odzwierciedlać ich jezioro danych, bez względu na to, czy zadziała, czy nie, i bez testowania, ponieważ wiedzą, co robią. Wtedy będą zaskoczeni, gdy złożone obiekty przechowywane w oddzielnych dokumentach, takich jak „zamówienia”, będą miały mniej „pozycji zamówienia” niż oczekiwano, a może wcale. Ale nie będzie się to zdarzać często lub na tyle często, że po prostu maszerują naprzód. Mogą nawet nie napotkać problemu w rozwoju. Następnie, zamiast przeprojektowywać, będą rzucać „opóźnienia”, „ponowienia” i „sprawdzenia”, aby sfałszować relacyjny model danych, który nie zadziała, ale zwiększy złożoność bez żadnych korzyści. Ale teraz jest już za późno - rzecz została wdrożona i teraz firma na niej działa. Ostatecznie cały system zostanie wyrzucony, a dział zostanie zlecony na zewnątrz, a ktoś inny będzie go utrzymywał. Nadal nie będzie działać poprawnie, ale mogą zawieść mniej kosztownie niż obecna awaria.

ggb667
źródło
0

Ostateczna spójność przypomina bardziej widmo. Z jednej strony masz silną konsekwencję, az drugiej ostateczną konsekwencję. Pomiędzy są poziomy, takie jak Migawka, przeczytaj moje pisma, ograniczona nieaktualność. Doug Terry ma piękne wyjaśnienie w swoim artykule na temat ostatecznej konsekwencji w baseballu .

Według mnie ostateczna spójność to po prostu tolerancja na losowe dane w losowej kolejności za każdym razem, gdy czytasz z magazynu danych. Wszystko lepsze niż to jest silniejszym modelem spójności. Na przykład migawka zawiera nieaktualne dane, ale zwróci te same dane, jeśli zostanie ponownie odczytana, więc jest przewidywalna. Czasami aplikacja może tolerować dane, które są nieaktualne przez określony czas, po przekroczeniu którego wymaga spójnych danych.

Jeśli spojrzysz na znaczenie spójności, odnosi się ona bardziej do jednolitości lub braku odchyleń. Zatem w kategoriach niezwiązanych z systemem komputerowym może to oznaczać tolerancję na nieoczekiwane zmiany. Można to bardzo dobrze wyjaśnić za pomocą bankomatu. Bankomat może być w trybie offline, co może odbiegać od salda konta w systemach podstawowych. Istnieje jednak tolerancja dla pokazywania różnych sald w określonym przedziale czasu. Gdy bankomat przejdzie do trybu online, może zsynchronizować się z podstawowymi systemami i zachować tę samą równowagę. Można więc powiedzieć, że bankomat jest ostatecznie spójny.

Shripad
źródło