There still might be some benefit to segregating your data into multiple
buckets, but that will largely depend upon what your most common query is.
Also consider carefully your choice of key; choosing a suitable one will let
you bypass map/reduce on certain queries.
That said, Alexander is rig
Unfortunately, there is no offset, limit, sorted set or pagination
built in to riak. You kinda need to maintain your own index for any of
that and/or rely on m/r in a less than real-time sort of way. I would
take your day keys and make them smaller... Like hours or even
minutes. The number
I think I understand your suggestion regarding an additional index in
other buckets.
To use your "keys per time slice" example, if I wanted to get all of
last month's phone call records, I will have already built up a
bucket-key pair that contains a list of keys...
GET /riak/callreport/2010_03
[
I would go with A. An advantage of your data is that it is immutable.
Since it never changes you can do extensive m/r pre computations and
have them run continuously on some frequency. I would also probably
spend some time thinking about the new pre/post hook features to
potentially build s
