This was also posted on Stack Overflow, but I suspect I should have looked here
first.
We have an application that could hugely benefit from using a document-based
data store like CouchDB. But we have a query use-case which I'm struggling to
implement with Map Reduce.
Our documents really only contain two types of data:
Numeric attributes
Boolean attributes
The boolean attributes essentially mark a document as belonging to one or more
non-exclusive sets. The numeric attributes will always only need to be summed.
One way of structuring the document is like this:
{
"id": 3123123,
"attr": {"x": 2, "y": 4, "z": 6},
"sets": ["A", "B", "C"]
}
With this structure, it's easy to work out aggregate x, y, z values for the
sets A, B and C, but it gets more complicated when you want to see the
aggregates for intersections like A&C.
In this small case I could emit keys for all permutations of ABC ("A, B, C, AB,
AC, BC, ABC"), but I'm worried about how this will scale. Our documents could
belong to some combination of 80 sets and it is fronted by a user-interface
which can construct any conceivable combination of them.
I'm inclined to think that this isn't a job for a CouchDB, and perhaps MongoDB
or something else would be better suited to this problem.
Am I missing anything?
Regards,
Brendon McLean
