Jakie są wady korzystania z Event sourcing i CQRS?

Question

Jakie są wady korzystania z Event sourcing i CQRS?

Event sourcing i CQRS jest świetny, ponieważ sprawia, że deweloperzy rids utknęli z jedną wstępnie modelowaną bazą danych, z którą programista musi pracować przez cały okres użytkowania aplikacji, chyba że istnieje projekt migracji dużych danych. CQRS i ES ma również inne korzyści, takie jak skalowanie eventstore, dziennik audytu itp. które są już w całym Internecie.

Ale jakie są wady ?

Oto kilka wad, które mogę wymyślić po zbadaniu i napisaniu małe aplikacje demo

złożone: niektórzy mówią, że ES jest złożone. Ale powiedziałbym, że posiadanie złożonej aplikacji jest lepsze niż złożony model bazy danych, na którym można uruchamiać tylko bardzo ograniczone zapytania za pomocą języka zapytań (wiele złączeń, indeksów itp.). Chodzi mi o to, że niektóre języki programowania, takie jak Scala, mają bardzo bogatą bibliotekę kolekcji, która jest bardzo elastyczna, aby produkować niektóre poważnie złożone agregacje, a także jest Apache Spark, który ułatwia odpytywanie rozproszonych zbiorów. Ale bazy danych zawsze będą ograniczone do możliwości języka zapytań, a dystrybucja baz danych jest trudniejsza niż Dystrybucja kodu aplikacji (wystarczy wdrożyć inną instancję na innym komputerze!).
wysokie wykorzystanie miejsca na dysku : magazyn zdarzeń może w końcu zużywać dużo miejsca na dysku do przechowywania zdarzeń. Ale możemy zaplanować sprzątanie co kilka tygodni i tworzenie migawek i może być możemy przechowywać wydarzenia historyczne lokalnie na zewnętrznym HD tylko okrywać potrzebujemy starych wydarzeń w przyszłości ?
wysokie zużycie pamięci : Stan każdego obiektu domeny jest przechowywany w pamięci, co może zwiększyć zużycie pamięci RAM i wszyscy wiemy, jak droga jest PAMIĘĆ RAM. WIELKI PROBLEM!!Ponieważ jestem biedny! jakieś rozwiązanie ? Może być użycie Sqlite zamiast przechowywania stanu w pamięci ? Czy robię rzeczy bardziej skomplikowane, wprowadzając wiele instancji Sqlite w mojej aplikacji ?
dłuższy czas rozruchu: w przypadku awarii lub aktualizacji oprogramowania uruchamianie jest powolne w zależności od liczby wydarzeń. Ale możemy użyć migawek, żeby to rozwiązać ?
ewentualna spójność : Problem dla niektórych aplikacji. Facebook Facebook wykorzystuje Event sourcing z CQRS do przechowywania postów i biorąc pod uwagę, jak zajęty jest system Facebooka, a gdybym opublikował post, zobaczyłbym mój post na FB następnego dnia:) {]}
zdarzenia serializowane w Event store: zdarzenia przechowują zdarzenia jako obiekty serializowane, co oznacza, że nie możemy odpytywać zawartości zdarzeń w Event store, co nie jest zalecane w każdym razie. I nie będziemy mogli dodać kolejnego atrybutu do wydarzenia w przyszłości. Rozwiązaniem byłoby przechowywanie zdarzeń jako obiektów JSON zamiast serializowanych zdarzeń ? Ale czy to dobry pomysł ? Lub dodać więcej zdarzeń w celu obsługi zmiany w obiekcie zdarzenia orignal ?

Czy ktoś może skomentować wady, które tu poruszyłem i poprawić mnie, jeśli się mylę I zasugerować Inne, które mogłem pominąć ?

20

cqrs event-sourcing

Author: hajime, 2015-10-22

Source

3 answers

Tylko skomentować punkt 5. Powiedziano mi, że Facebook używa ES z ewentualną konsekwencją, dlatego czasami możesz zobaczyć, jak post zniknie i pojawi się ponownie po opublikowaniu go.

Zazwyczaj model odczytu przeglądarki znajduje się 'blisko' do ciebie, ale po napisaniu postu SPA przełącza się na model odczytu, który jest blisko Twojego modelu zapisu. Bliskość pomiędzy modelem zapisu (zdarzeniami) a modelem odczytu oznacza, że możesz zobaczyć swój własny poczta.

Jednak 15 minut później twoje SPA przełącza się z powrotem na pierwszy, bliższy, model odczytu. Jeśli wydarzenie zawierające twój post nie rozprzestrzeniło się jeszcze do tego modelu odczytu, zobaczysz, że twój własny post zniknie, aby ponownie pojawić się jakiś czas później.

5

Author: Sam Stickland,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-01-07 18:04:35

Wiem, że minęło prawie 3 lata od tego pytania, ale mimo to Ten artykuł może się komuś przydać. Kluczowe punkty to

skalowanie za pomocą migawek
widoczność danych
zmiana schematu
zajmowanie się złożonymi domenami
trzeba wyjaśnić to większości nowych członków zespołu

0

Author: kagetoki,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-07-23 14:37:11

score 25 · Accepted Answer

Oto moje zdanie na ten temat.

CQRS + ES może znacznie uprościć złożone systemy programowe, mając bogate obiekty domenowe, proste modele danych, śledzenie historii, większy wgląd w problemy z współbieżnością, skalowalność i wiele więcej. Wymaga to innego myślenia o systemach, więc znalezienie wykwalifikowanych programistów może być trudne. Ale CQRS ułatwia rozdzielenie obowiązków między deweloperów. Na przykład młodszy programista może pracować wyłącznie z czytaną stroną bez konieczności dotykania logiki biznesowej.
Kopie danych z pewnością będą wymagały więcej miejsca na dysku. Ale Przechowywanie jest stosunkowo tanie w dzisiejszych czasach. Może to wymagać od zespołu wsparcia IT, aby zrobić więcej kopii zapasowych i zaplanować, jak przywrócić system w przypadku, gdy coś pójdzie nie tak. Jednak obecnie wirtualizacja serwerów sprawia, że jest to bardziej usprawniony przepływ pracy. Ponadto znacznie łatwiej jest stworzyć redundancję w systemie bez monolitycznej bazy danych.
Nie wiem. rozważ większe zużycie pamięci jako problem. Nawodnienie obiektu biznesowego powinno być wykonywane na żądanie. Obiekty nie powinny zawierać odniesień do zdarzeń, które już zostały utrzymane. Nawodnienie zdarzenia powinno nastąpić tylko wtedy, gdy dane są utrzymywane. Po stronie odczytu nie masz konwersji Entity -> DTO -> ViewModel, które zwykle miały miejsce w systemach warstwowych, i nie masz żadnego rodzaju śledzenia zmian obiektów, które zwykle robią pełne funkcjonalne ORM. Większość systemów wykonuje znacznie więcej odczytów niż pisze.
Dłuższy czas rozruchu może być niewielkim problemem, jeśli używasz wielu heterogenicznych baz danych z powodu inicjalizacji różnych kontekstów danych. Jeśli jednak używasz czegoś prostego, takiego jak ADO. NET do interakcji ze sklepem zdarzeń i mikro-ORM dla strony odczytu, system "uruchomi się" szybciej niż jakikolwiek w pełni funkcjonalny ORM. Ważne jest, aby nie komplikować zbytnio dostępu do danych. To jest właściwie problem, który CQRS ma rozwiązać. I jak ja powiedziane wcześniej, strona odczytywana powinna być modelowana dla widoków i nie powinna mieć żadnych kosztów ponownego mapowania danych.
Dwufazowy commit może działać dobrze dla Systemów, które nie muszą skalować się dla tysięcy użytkowników z mojego doświadczenia. Musisz wybrać bazy danych, które będą dobrze współpracować z koordynatorem transakcji rozproszonych. PostgreSQL może pracować na przykład dla odczytu i zapisu oddzielnych modeli. Jeśli system musi być skalowany dla dużej liczby jednoczesnych użytkowników, musiałby być zaprojektowany z myślą o ewentualnej spójności. Istnieją przypadki, w których masz zagregowane korzenie lub granice kontekstu, które nie używają CQR, aby uniknąć ewentualnej spójności. Ma to sens dla części domeny, które nie współpracują ze sobą.
Możesz odpytywać zdarzenia w formacie serializowanym, takim jak JSON lub XML, jeśli wybierzesz odpowiednią bazę danych dla magazynu zdarzeń. I to powinno być zrobione tylko dla celów analitycznych. Nic wewnątrz systemu nie powinno odpytywać magazynu zdarzeń o cokolwiek innego niż zagregowany identyfikator główny i typ zdarzenia. Dane te byłyby indeksowane i żywe poza serializowanym zdarzeniem.