Mireczki pytanie. Załóżmy, że chcę zbudować serwis w oparciu o #eventsourcing Gdzie trzymacie wszystkie zdarzenia? W bazie noSQL-owej? A w bazie relacyjnej wyliczone finalne wartości (te tzw. projekcje)?
Przecież po 2,3 i np. 5 latach działania takiego systemu eventów będę miał od cholery, baza SQL-owa raczej tego nie utrzyma.
@Dyktus: Często się do tego stosuje np. kafkę + cassandrę. Eventy konsumujesz z kafki z cassandry odbudowujesz stan aplikacji w razie jakiegoś padu lub gdy potrzebujesz wyciagnąć coś starego czego na kafce już nie znajdziesz
@Dyktus: A i mi się właśnie przypomniało, że z kafką i php jest jakiś problem, nie pamiętam czy brakuje bibliotek czy coś z nimi jest nie tak, ale jak używaliśmy kafki z php to całość komunikacji szła przez kafka rest proxy co w przypadku eventsourcingu traci sens
@pitu120: A ja używałem i polecę, tylko, że Broadway to libka a nie baza danych @Dyktus: może być nosqlowa, chociaz nie wiem skąd pomysł, że baza sqlowa Ci tego nie utrzyma, jak to się ekstremalnie łatwo partycjonuje, jak bedziesz potrzebował więcej eventów trzymać to partycjonowanie po dacie i tyle
@LiczbaPi: nie jestem pewien czy w ogóle odpowiedziałeś na jego pytanie, tzn on pyta o persystencji zdarzeń, a kafka tutaj nijak się do persystencji nie ma :P
Załóżmy, że chcę zbudować serwis w oparciu o #eventsourcing
Gdzie trzymacie wszystkie zdarzenia? W bazie noSQL-owej? A w bazie relacyjnej wyliczone finalne wartości (te tzw. projekcje)?
Przecież po 2,3 i np. 5 latach działania takiego systemu eventów będę miał od cholery, baza SQL-owa raczej tego nie utrzyma.
#programowanie
Może pokombinuje żeby przesiąść się na jave w końcu ^^
Nie wypowiem się osobiście na jego temat bo nie używałem
@Dyktus: może być nosqlowa, chociaz nie wiem skąd pomysł, że baza sqlowa Ci tego nie utrzyma, jak to się ekstremalnie łatwo partycjonuje, jak bedziesz potrzebował więcej eventów trzymać to partycjonowanie po dacie i tyle