Getting a list of events using secondary index
brady at bespincorp.com
Thu Oct 17 16:42:14 EDT 2013
You don't say _how_ you get the last_event_id for a particular aggregate -
but presuming that's a relatively trivial operation - you could change
around your secondary index so you just have to make a range query.
Instead of - or possibly in addition to - the aggregate_id, you could have
an aggregate_id_event_id composite index, which contains something like
"<aggregate_id>:<event_id>". Then, for a query for aggregate_id "x", you
would do a range query for x:<last_event_id> to x:999999999999
After that, you'd still have to do the multi-key get to grab your events.
But if the number of events per aggregate is 'very large' and the number of
events per aggregate greater than last_event_id is "small", then it could
On Thu, Oct 17, 2013 at 3:53 PM, Alex Robson <asrobson at gmail.com> wrote:
> Working on an event-sourcing aproach and would really appreciate some
> 1. Every event is tagged with a secondary index ("aggregate_id")
> 2. Every event's id is k-ordered (using a Flake compatible id generator)
> 3. Every aggregate has last_event_id
> I would like the ability to select all event ids, for a given an
> aggregate_id that occurred after the last_event_id for a given aggregate.
> At the moment, I am using the secondary index only to get all event ids
> for a particular aggregate. I then filter the id list so that I only have
> the ids that occurred after last_event_id. I then issue a multi-key get and
> retrieve the events I want.
> Latency is fairly important in this case and so I wanted to see if there
> were a better way (or if what I'm doing is just an awful misuse of Riak). I
> got the impression from reading docs that map/reduce is not ideal for
> real-time operations and intended more for batch stuff that runs out of
> band. This series of operations would occur for every read of the aggregate.
> Thanks for your help and thanks for Riak :)
> riak-users mailing list
> riak-users at lists.basho.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users