As mentioned in part 3, with the EventSourced approach there is
technically no need for snapshots for reading at all. If all your system
ever does is create new objects, but never read anything (i.e.
getEntityState() is never called), then only the /changes REST endpoint
is necessary, and so no reader databases will be needed.
But if you do have readers accessing the /entity endpoint, there are a
number of questions that arise:
*) Do you apply all changes? If the reader is partitioned there's no
need for this. Basically the reader can use this logic: if there is a
request to /entity for a particular id it can assume that is been
selected to serve that object by a content router. This means that when
reading /changes it should apply changes to that id. Any id's that have
not been served can be safely ignored. For the first request to an id
(e.g. if the reader has just been put into use, or the partitioning has
changed) the reader can either read through all changes to get the
up-to-date snapshot for that id, or it can ask the backup server for the
snapshot, as it would always have all objects in it. The backup server
needs to have all data for completeness, whereas the partitioned reader
needs to have a subset in order to increase performance of reads to it.
By working together they can ensure that both of their objectives are met.
*) When do you apply changes? In a sense a reader does not have to get
changes until a request to /entity is actually performed. The client of
the /entity call will not know whether the reader actually had the
state, or if it compiled it on the fly by asking for changes! The result
is a bit zen-like: if noone is around to read the database, it doesn't
exist. I find the comparisons with philosophy and physics (does the
universe exist if noone is around to perceive it?) to be more than
slightly humorous.
One question is how to choose which server to ask for what id's, i.e.
how to do the actual partitioning. I think the referenced article on
consistent hashing pretty much answers that, and it will be very
interesting to see just how good it will work in this context.
This is the last of what I figured out on the plane back from Bali.
Pretty interesting stuff in my view, and it doesn't seem all that hard
to implement.
Comments on this?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
