Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 89407 invoked from network); 29 Sep 2010 14:28:33 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 29 Sep 2010 14:28:33 -0000 Received: (qmail 23020 invoked by uid 500); 29 Sep 2010 14:28:31 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 22566 invoked by uid 500); 29 Sep 2010 14:28:27 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 22558 invoked by uid 99); 29 Sep 2010 14:28:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Sep 2010 14:28:26 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [213.165.82.234] (HELO smeagol.fto.de) (213.165.82.234) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Sep 2010 14:28:19 +0000 Received: from smeagol.fto.de (unknown [127.0.0.1]) by smeagol.fto.de (Postfix) with ESMTP id 8514E3004D593 for ; Wed, 29 Sep 2010 14:27:56 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=fto.de; b=vb/K9aF6EoqTmOE+SfjilxzOxaQ+UPmiVLjFR//MHAb7LYIV9K4GfJVgDajeQcHKLAyposNeZLqXoxSLavkc/dFeO8S18G8Q8vLO7Nr0Jfb/GoZagrzvllDjX+7ob4pv; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: from giskard.foundation.hs (unknown [80.128.215.134]) by smeagol.fto.de (Postfix) with ESMTPA for ; Wed, 29 Sep 2010 14:27:56 +0000 (UTC) Received: from [IPv6:::1] (daneel.foundation.hs [192.168.20.2]) by giskard.foundation.hs (Postfix) with ESMTP id F2F35179126 for ; Wed, 29 Sep 2010 16:27:57 +0200 (CEST) Message-ID: <4CA34CED.6000207@fto.de> Date: Wed, 29 Sep 2010 16:27:57 +0200 From: Heiko Schaefer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Efficient couchdb queries with explicitly specified keyset of >1000 IDs? X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Couchdb-User-List, I'm building a little family of REST-services with couchdb over the past months and have made a lot of progress. It's a great experience to get to know and use couchdb. Right now I'm trying to figure out how to implement a new requirement - and I feel a little lost. Here's what I am considering, and would like to know if it sounds at all feasible: I expect to have on the order of 100.000 documents in my couchdb, very soon. But an (independent and external) service may define groups of documents (a few thousand documents being one group). I'd like to be able do searches (query couchdb views) on just the subset of documents that are in one group. I'm not very keen to mark my documents themselves as members of a group, if it can be at all avoided. So I thought maybe I can make queries that explicitly list the relevant few thousand couch IDs in queries. Example use-case: There are 100.000 documents in the couchdb. An externally supplied list specifies a subset of 5.000 IDs. I'd like to efficiently query a view, but only considering the documents within this subset of 5.000 IDs. Then I would like to further narrow down these results by other keys. [The IDs would probably not map 1:1 onto the couchdb "_id", but rather onto another field (or two) of the documents] Would that be as mad (and inefficient) as it sounds? Is there any other way to achieve my objectives with couchdb that I might be missing? Sorry if my question is not worded properly or clearly - I don't feel fluent in the couchdb terminology and way of thinking yet. Thanks in advance for any help and pointers. cheers, :) Heiko