Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of brendon.mclean@gmail.com
 designates 74.125.82.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=QDD61oMjKkLfdNjmC7BNWbJlxCRTp9tHs7g1TWR9pS/zXTowMyWHEHbLNCH/Ui8C5/
         jwxsZPhjpUTG/n2HYpmzQheOKpeYlvVQmbb32X/mwsPW0wJW6q+voFcrp4zzH622I4W5
         UeVZTbRH4Xh/pcSbYYPSUmGwOBj4demRw9snE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: Re: Strategy for arbitrary predicate queries in Couchdb
From: Brendon McLean <brendon.mclean@gmail.com>
In-Reply-To: <4D3D88E3.5080507@zedeler.dk>
Date: Mon, 24 Jan 2011 17:42:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <37DAF263-40BB-4D56-A9DD-202E2B95CE32@gmail.com>
References: <38934C4C-127F-4892-8236-A7957BFAA1A3@gmail.com>
 <4D3D88E3.5080507@zedeler.dk>
To: user@couchdb.apache.org

Hi Michael,

I'm not sure how you would do that.  The predicates are non-exclusive so =
I'd have to literally perform the aggregation outside of the database.  =
I suppose if you went this way, you could check the document matches for =
each predicate, choosing the smallest set to examine outside of the =
database.

Regards,
Brendon.

On 24 Jan 2011, at 16:12 , Michael Zedeler wrote:

> On 2011-01-24 13:49, Brendon McLean wrote:
>> Our documents really only contain two types of data:
>>=20
>> 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:
>>=20
>> {
>>   "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.
>>=20
>> 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.
>>=20
>> 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.
> We have solved the problem for attributes by creating one index for =
each attribute (running one query for each index) and then just =
aggregating the results after.
>=20
> Regards,
>=20
> Michael.
>=20