Trzymanie migawki najnowszej wersji każdego agregatu w magazynie zdarzeń

Question

Obecnie korzystamy z magazynu zdarzeń opartego na języku SQL (typowa implementacja 2-tabelowa), a niektórzy ludzie w zespole obawiają się, że mimo tego " ponowne używanie Event Store tylko do zapisywania, rzeczy mogą być nieco wolniejsze, więc została wprowadzona sugestia zamiast dodawać migawki tu i tam, aby faktycznie utrzymywać w pełni spójne (ze strumieniami zdarzeń) migawkę każdego agregatu w jego najnowszy stan (w formacie JSON). Wszystkie zapytania w systemie zostaną zakończone po stronie odczytu, z typową bazą danych SQL, która jest aktualizowana w ostatecznej formie spójności ze strony ES (zapis).

Posiadanie takiego systemu pozwoli nam czerpać korzyści z posiadania Sklepu z Wydarzeniami, jednocześnie usuwając wszelkie możliwe problemy z wydajnością. W tej chwili nie korzystamy z żadnej funkcji "podróży w czasie", ale prędzej czy później tak się stanie.

Czy to dobre podejście? Jest w tym coś, co sprawia, że ​​czuję się nieswojo. Na przykład, jeśli potrzebujemy jakiejś funkcji podróżowania w czasie, nie posiadanie migawek tu i tam w strumieniu zdarzeń każdego agregatu okaże się katastrofą wydajności. Oczywiście możemy mieć zarówno najbardziej aktualną migawkę na zagregowaną instancję, jak i migawki w strumieniach zdarzeń.

Jeśli zdecydujemy się na tę trasę, czy powinniśmy zrobić aktualizację snapshot dla danej zagregowanej transakcji do aktualizacji wydarzeń w tym samym agregacie, czy też powinniśmy po prostu zaktualizować zdarzenia i w konsekwentny sposób zaktualizować migawka?

Jakie są wady tego podejścia? Czy ktoś próbował czegoś takiego?

Answer 1

Najprawdopodobniej powinieneś uruchomić własne testy porównawcze, zanim dodasz niepotrzebny komplikacji do swojego systemu. Zauważyliśmy pewne problemy z wydajnością, gdy trzeba przetestować tysiące zdarzeń i zastosować je do odbudowania agregatu ze strumienia zdarzeń, gdzie JSON do przekształcania obiektów w obiekt był największym wąskim gardłem wydajności. Jeśli każdy z Twoich agregatów ma tylko kilka zdarzeń (powiedzmy: < 100) prawdopodobnie nie zauważysz żadnych znaczących różnic w praktyce.

Większość magazynów zdarzeń rejestruje migawki co każdezdarzeń/zatwierdzeń, powiedzmy co 50-100 zdarzeń, a na złożeniu odpytuje najnowsze migawki i stosuje brakujące zdarzenia od czasu ostatniego migawki. Jeśli zachowasz wszystkie stare migawki w swojej migawkowej bazie danych, funkcja podróżowania w czasie będzie tak szybka, jak zwykłe zapytanie, a będziesz potrzebował tylko nieco więcej przestrzeni trwałości, która jest tania w dzisiejszych czasach.

Migawki powinny być zawsze zapisywane z oryginalnej transakcji (i mogą być generowane w innym wątku), ponieważ nie ma to znaczenia, jeśli brakuje ostatniej migawki, ale nie chcesz, aby transakcja biznesowa zawiedzie z powodu błędów w transakcji zapisu migawki.

W zależności od uptime systemu i rozmiaru danych, może być sens przechowywanie migawek w pamięci lub rozproszonej pamięci podręcznej/graid lub w innej bazie danych (nie SQL).