@bitbonk@bitbonk good question! Indeed, the IoT model seems to be aligned with Event Sourcing, as we're listening for the events and then doing interactions. The main issue is the nature of data coming from machines and the frequency. In Event Sourcing events gather business value 1/
@bitbonk IoT data is usually raw. Also, the number of measurements and their frequency can be really high, especially for the really busy production line. Most of the event stores are not so lightweight. So they not always can be run on e.g. raspberry pi. 2/
@bitbonk Also, quite often, they have a bigger frequency than event stores can handle per second. The common pattern is to do the data ingestion. So using lightweight, but fast type of storage (e.g. key/value) or queue that will batch the events from IoT, group and change into events /3
@bitbonk This event transformation is both for performance reason but especially for making the raw events a business meaningful. I know that Postgres can be run at Raspberry PI, so maybe @marten_lib also (I didn't try that tho, probably I should 😅). .NET is also getting lightweight /4
@bitbonk@marten_lib .NET 6 should provide more optimisation and simplification. @eventstore in one of the next versions should be also possible to run on ARM, which can open more options. I haven't run .NET on Edge devices, but that's a tempting and interesting use case.
Did that help? 😅 5/5
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@mzagozda Dziękuję bardzo! Cieszę się, że się podobało 🤩 Bardzo dobre pytanie.
Zacznijmy od tego, że sam Event Sourcing jest wzorcem, który co prawda o tym mówi, jak przechowywać dane, a w zasadzie nie tyle jak co w jakiej formie - konkretnie zdarzeń. Jednak sam w sobie nie mówi gdzie 1/
@mzagozda Zatem moglibyśmy przechowywać te zdarzenia równie dobrze w pliku tekstowym, binarnym, excelu, xmlu, json, czy też już bardziej rzeczywiście w bazie danych. No i tutaj w zależności od tego jaka jest charakterystyka naszego miejsca przechowywania takie mamy też możliwości 2/
@mzagozda Jeżeli korzystamy z jakiegoś rozproszonej bazy danych to może to być faktycznie utrudnione. Większość z nich ma możliwość tylko "symulowania" takiej weryfikacji (np. DynamoDB aws.amazon.com/blogs/database…). Zwykle jest to przy symulowane poprzez algorytmy rozwiązywania konfliktów /3
@HaripraghashS@HaripraghashS 2 short questions without 2 short answers 😅But let's try! Projections for me when I started my journey with #EventSourcing was the hardest thing to understand. I thought: ok, I can rebuild the aggregate state by replaying events one by getting them by id 1/
@HaripraghashS Having that I'll have the state of the single aggregate. Wait a minute! If I won't to do that for the aggregate list then I'd need to get all events for those aggregates and reply it one by one? Nah that's can't be! For that we have we have projections. As you for sure know /2
@HaripraghashS What are projections? It's just representation and interpretation of the set of event. What's more when we're replying events to get aggregate state - that's also projection. It's easy to forget about that because it's default case. We're just interpreting events to get state /3