Does it fit to CRDT?


(Hsnamed) #1

We have domain :

  • 10.000 long lived " event " objects , i think about to create an actor for each of them.

  • Each " event " contains < 250 entities like " factgroup " .

  • Each factgroup contains < 6 fact entities : fact entity has 2 - long counters and boolean state that has changed in any direction.

  • Payload - message that change the counters in fact entity.

FactGroup must has changed atomically :

  • each payload usually affects all facts

  • state of each fact depedns on calculation result of 2 fact counters.

State of fact and counters of fact is the most important thing, so i left idea about LWWMap<FactGroup>.

Also thinked about extending AbstractReplicatedData, AbstractDeltaReplicatedData as a chance to make crdt Map of FactGroup

Does it fit to CRDT ?

Could someone suggest the right way to implement crdt ?


(Patrik Nordwall) #2

I think that can be a good fit.

10000 should be ok to have as top level entries, if those are static (removing a top level entry leaves a small tombstone). If more would be needed or they are added/removed more dynamically you can use a few (e.g. 1000) ORMap as top level and each such map holds 10-100 factgroup (hashing to select map).

Creating a custom CRDT for the FactGroup sounds good. It can be a composite existing, such PNCounter or PNCounterMap. Be careful with serialization though (don’t use Java serialization). However, if it’s only a bunch of counters and a boolean it might be easier to model all that as a single PNCounterMap (the boolean can be a counter switching between 0 and 1).


(Hsnamed) #3

Thank you Patrik , it was very helpful !
I have composed FactGroupCrdt from built in types.

Are there any abilities to subscribe to changes but if ORMap has changed i want to catch changed items not just ORMap full state , in my case when FactGroupCrdt has changed ?

As i said before i going to make 10к Actors for it , should i make more replicators for that , one replicator per 1000 actors as example ?


(Patrik Nordwall) #4

The change events are per top level entry so you have to do that by keeping old state and diff.

You have to test the performance aspects. Start with one and see and measure.