Secondary indexing  Bryan O'Sullivan bos at Fri Apr 22 16:45:50
EDT 2011  In my application, I have a frequent need to store
collections of data where I rarely access the items
individually, but much more commonly in aggregate form. In
principle, the mapreduce feature is well suited to this, but it
must be fed a set of {bucket,key} pairs to consume, and
maintaining these collections is painful.  The naive approach
would be to store each collection in its own bucket, and use
listkeys to fetch the keys that I can then mapreduce over.
However, listkeys has red flags all over it, presumably because
it's implemented as a scan+filter of all buckets and keys.  The
slightly less naive approach would be to store the keys for a
collection in a list. Unfortunately, for a collection of even
modest size (10,000 elements), the cost of retrieving and
storing this index to make small changes (e.g. "I'm adding one
element to the collection") rapidly becomes untenable, and
that's before such knotty issues as "how do I delete i