Nie korzystaj z Axona i list

To nie jest tak, że w Axonie w agregatach i sagach nie można korzystać z list. Jeżeli kolekcja zawiera niewielką ilość elementów, około 1000, to nie ma problemu. Jeżeli jednak wymagana jest obszerniejsza lista to napotykamy problemy pamięciowe i wydajnościowe. Co należy zrobić aby nie mieć takich problemów?

Problem pamięci masowej

Przechowywanie dużych kolekcji w sadze powoduje duże zużycie pamięci masowej.

Przyczyna

Podczas zapisywania stanu sagi po przetworzeniu zdarzenia, przy wykorzystaniu JPA, stan jest zapisywany w nowym obiekcie w Postgresie. Powoduje to namnożenie obiektów przechowujących stan sagi.

Jeżeli  w sadze mamy listę 1000 UUIDów zajmujących po 128 b i przetworzy ona 1000 zdarzeń, przez co będzie zapisana 1000 razy, to baza zwiększy swój rozmiar o 128 mb.

Rozwiązanie

Konfiguracja JdbcAutoConfiguration pomaga. Po jej zastosowaniu  stan sagi nie będzie zapisywany jako obiekt a kolumna w bazie danych, przez co nowy stan sagi nadpisze stary. Najlepiej po prostu unikać dużych list w sagach. Jeżeli musimy zapisać dużą kolekcję wtedy trzeba stworzyć na nią dodatkową tabelę w bazie danych lub wykorzystać brokera wiadomości. My skorzystaliśmy z drugiej propozycji. Podczas przetwarzania jednego ze zdarzeń na RabbitMQ wysyłamy rozkazy, które następnie zostają ściągnięte i wrzucone na CommandBus.

Problem prędkości przetwarzania

Agregaty czy sagi przechowujące duże listy długo się wczytują i zapisują.

Przyczyna

Axon serializuje i deserializuje długą listę na xmla lub jsona. 

Rozwiązanie

Usuwamy listę. Dla agregatu rozwiązanie jest proste, elementy z listy stają się agregatami, nie ma tu innego rozwiązania. Z sagami może być większy problem lecz najczęściej ta duża lista nie będzie nam potrzebna lub możemy wykorzystać pomysły z wcześniejszego rozwiązania. W jednym z naszych przypadków listę udało zastąpić się zliczaniem opublikowanych zdarzeń.

Wersja Axon: 3.3.0