Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <h2r5b7f441e1004201842gddc05430r7811cdb76bb711a9@mail.gmail.com>
References: <j2q2fc10a851004201808ib43c1e31i831e5d61abbb97a@mail.gmail.com>
	 <h2r5b7f441e1004201842gddc05430r7811cdb76bb711a9@mail.gmail.com>
Date: Tue, 20 Apr 2010 22:27:04 -0400
Message-ID: <i2r64a10fff1004201927m6d7d3b61wf1c8b9855a41e97d@mail.gmail.com>
Subject: Re: Intersecting several views
From: Dean Landolt <dean@deanlandolt.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=0016e6d77c4511b2bf0484b5ee43

--0016e6d77c4511b2bf0484b5ee43
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 20, 2010 at 9:42 PM, Ning Tan <ningtan@gmail.com> wrote:

> On Tue, Apr 20, 2010 at 9:08 PM, Nick Poulden <nick@domine.co.uk> wrote:
> > My question is how to approach this filtering problem with couchdb. At
> the
> > moment I have different views on 'account_type', 'registration_date' and
> > 'last_login_date'. My program queries each view separately and returns an
> > intersection of the resulting key arrays. This is working ok while my
> > database is small but it's not very scalable as all the document keys
> have
> > to be loaded in to memory before the intersection can happen.
>
> For these "ad hoc" queries, I would suggest a separate indexing system
> (e.g. Couch-Lucene, etc).
>
> We use a Solr system for similar purposes.
>

Historically the solution to this problem has always been *run all your
changes through something else*. I'm pretty down on that as an actual
solution -- it's feasible but makes *something else* a pretty bigass
bottleneck. Now you have to have a distributed *something else* and a
distributed couch -- there's obvious benefits to a distributed couch but
your *something else* is just serving up answers to specific ad-hoc
questions...

There's a pretty slick solution built into couch -- replication -- but the
hard part is getting couch's replication to talk to your *something else*.
I'm trying to fix that now, and it ought to be easy. I'll hit this list back
once I get couch replication working on persevere 2.0 but the idea is all
your couch _changes should be able to flow into some other defined store
(mongo, lucene, sql, whatever) and from your couchapp (or anywhere else) you
should be able to hit your *something else* to resolve multiterm queries.

I'll post back in a few days but just wanted to jump in and point out that
this kind of thing ought to be totally doable.

--0016e6d77c4511b2bf0484b5ee43--