W praktyce, jak ostatecznie jest "ostateczna konsekwencja" w HRD?

Question

Jestem w trakcie migracji aplikacji z Master/Slave do HRD. Chciałbym usłyszeć kilka komentarzy od osób, które przeszły już migrację.

1. Próbowałem prosty przykład po prostu opublikować nowy podmiot bez przodka i przekierowanie do strony, aby wymienić wszystkie podmioty z tego modelu. Próbowałem go kilka razy i zawsze było to zgodne. Stawiam 500 indeksowanych właściwości i znowu, zawsze spójne ...

2. Martwiłem się również o pewne roszczenia o limit jednego zakładu (1) na grupę jednostek na sekundę. Umieszczam() 30 elementów z tym samym przodkiem (to samo żądanie HTTP, ale put() jeden po drugim) i zasadniczo nie było różnicy od umieszczenia 30 obiektów bez przodka. (Używam NDB, może to robić jakąś optymalizację?)

testowałem to z pustym aplikacji bez ruchu i zastanawiam się ile prawdziwy ruch wpłynie na „ostateczną konsystencję”.

Jestem świadomy mogę przetestować „ostateczną konsystencję” na rzecz rozwoju lokalnego. Moje pytanie brzmi:

Czy naprawdę trzeba zrestrukturyzować moją aplikację do obsługi ostateczną konsystencję?

Albo byłoby dopuszczalne zostawić to tak, to dlatego, że ewentualna konsekwencja jest rzeczywiście zgodne w praktyce do 99%?

Answer 1

Jeśli masz małą aplikację następnie dane prawdopodobnie mieszkają na tej samej części tego samego dysku i masz jedną instancję. Prawdopodobnie nie zauważysz ostatecznej konsekwencji. Wraz ze wzrostem aplikacji zauważysz to jeszcze bardziej. Zwykle osiągnięcie spójności zajmuje milisekundy, ale widziałem przypadki, w których zajmuje godzinę lub więcej.

Generalnie zapytań gdzie można zauważyć go najbardziej. Jednym ze sposobów zmniejszenia wpływu jest zapytanie tylko za pomocą kluczy, a następnie użycie polecenia ndb.get_multi() w celu załadowania encji.Pobieranie elementów za pomocą kluczy zapewnia, że ​​otrzymasz najnowszą wersję tego obiektu. Nie gwarantuje jednak, że lista kluczy jest silnie spójna. Możesz więc otrzymać obiekty, które nie pasują do warunków zapytania, więc przeprowadź pętle przez encje i pomiń te, które nie pasują do siebie.

Z tego, co zauważyłem, ból ostatecznej konsystencji rośnie stopniowo wraz ze wzrostem aplikacji. W pewnym momencie musisz potraktować to poważnie i zaktualizować krytyczne obszary kodu, aby go obsłużyć.

Answer 2

Jaki jest najgorszy przypadek, jeśli wyniki są niespójne?

• Czy użytkownik zobaczyć jakieś nieistotne informacje, która jest nieaktualna? To chyba w porządku.

• Czy przeliczyć coś ważnego, podobnie jak ceny czegoś? Lub liczbę przedmiotów w magazynie w sklepie? W takim przypadku chcesz uniknąć tego przypadkowego wystąpienia.

Z obserwacji tylko wydaje się, że ostatecznie spójne wyniki pokazują się bardziej jako zbioru danych staje się większy, podejrzewam, jak dane są podzielone między kilku tabletek.

Ponadto, jeśli czytasz swoje podmioty z powrotem get() żądania przez klucz/id, to zawsze będzie spójna. Upewnij się, że robisz zapytanie, aby uzyskać ostateczne wyniki.

Answer 3

Prędkość replikacji zależy głównie od obciążenia serwera. Zazwyczaj w nieobciążonym systemie opóźnienie replikacji wynosi milisekundy.

Ale idea „ostatecznie spójne” jest to, że trzeba napisać swoją aplikację tak, aby nie polegać na tym; wszelkie opóźnienia replikacji muszą być dopuszczalne w ramach ograniczeń Twojej aplikacji.