On 24 January 2011 14:49, Brendon McLean <[email protected]> wrote: > 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
Take a look at couchdb-lucene. Cheers, -- DU
