prolic on v1.10.3
prolic on master
update changelog (compare)
prolic on master
fix restarting projection durin… respect lock in memory resetting projection and 12 more (compare)
just released: https://github.com/prooph/event-store/releases/tag/v7.7.0
special thanks for @gquemener and also thank you @netiul for reminding me to take care of this.
spread the word!
Good afternoon @prolic @codeliner
We are currently use the prooph framework for our loyalty engine. In short we have a setup that on each transaction that is created, an x amount of events are created on the player aggregate
The problem is that before we start acting on the player aggregate, we first load the player aggregate (snapshots taken) and then append 1 or more events on it depending on the life-cycle of the loyalty engine campaign. We do have snapshots in place so its not as if we are loading the full history of the player. But still the query generated by the framework to load from snapshot (AggregateRepository -> loadFromSnapshotStore) is quite CPU heavy on the RW db, compared to other queries
In the past we did POC moving to the
AggregateStreamStrategy but as written in the documentation, we did struggle alot to have our projections as real time as possible. we would have 1000s of tables if we do one table per player.
So we are looking for options to perform better when loading the aggregate from a snapshot.
DBAs suggested to use partitioning of the main player aggregate table but not sure if prooph itself has that option. Otherwise if DBA create partitioned tables (prob one a day), then we need prooph framework to load the aggregate with these partitioned table.
Another idea that we had was to keep a parallel event store (inMemory) with the state of the players in the last 5mins. meaning that the player is kept in memory for around 5mins or even less.. that would drastically reduce the load on the db.
any other options/thoughts?
On a side note we are using
7.5.6 and we currently experience around 1.8million to 2million transactions at any given day. for each transaction we load the player aggregate (for the player related to that transaction) and append further events to the player aggregate
composer why-not php 8.0 prooph/event-store-http-middleware v0.2.0 requires php (^7.1) prooph/http-middleware v0.2.0 requires php (^7.1) prooph/pdo-snapshot-store v1.5.2 requires php (^7.1) prooph/standard-projections v1.1.1 requires php (^7.1)
yeah. i was lookin into how laminas does that these days. pretty advanced. wondering if that would be something prooph could depend on. Maybe saves a ton of work… dunno
all their repos now have this https://github.com/laminas/laminas-db/blob/2.16.x/.github/workflows/continuous-integration.yml which is capable of running various php version with extensions as needed and several tools…