From couchdb-user-return-1367-apmail-incubator-couchdb-user-archive=incubator.apache.org@incubator.apache.org Thu Sep 25 15:58:39 2008 Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 92979 invoked from network); 25 Sep 2008 15:58:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Sep 2008 15:58:39 -0000 Received: (qmail 56105 invoked by uid 500); 25 Sep 2008 15:58:33 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 56075 invoked by uid 500); 25 Sep 2008 15:58:33 -0000 Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-user@incubator.apache.org Delivered-To: mailing list couchdb-user@incubator.apache.org Received: (qmail 56055 invoked by uid 99); 25 Sep 2008 15:58:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Sep 2008 08:58:33 -0700 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gcdcu-couchdb-user@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Sep 2008 15:57:31 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KitEB-0005iW-Or for couchdb-user@incubator.apache.org; Thu, 25 Sep 2008 15:58:03 +0000 Received: from cpe-74-66-71-236.nyc.res.rr.com ([74.66.71.236]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Sep 2008 15:58:03 +0000 Received: from wschenk by cpe-74-66-71-236.nyc.res.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Sep 2008 15:58:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: couchdb-user@incubator.apache.org From: Will Schenk Subject: Re: 3 Newbie questions Date: Thu, 25 Sep 2008 11:54:55 -0400 Lines: 54 Message-ID: References: <122EE525-9024-4254-ABAA-985D5B507960@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpe-74-66-71-236.nyc.res.rr.com User-Agent: Unison/1.7.8 Sender: news X-Virus-Checked: Checked by ClamAV on apache.org On 2008-09-25 10:21:05 -0400, Jan Lehnardt said: > a) "The value returned from a reduce should grow at a rate no bigger > than log(N) of values processed". This is why you see your view being > slow. Where is this quote front? > > b) the back-and forth of data between CouchDB and Spidermonkey > certainly takes some time, but it is not the limiting factor here. A > document is indexed only once. Results are cached. Your first query > will go through all your data, all subsequent queries will be lighting > fast. If this is the case, then I'm certainly doing it wrong. Not really sure how do cache these views with relaxdb, but I'll figure out something. > See above, wrong conclusion. Treating databases as tables is a > terrible idea. Sorry RelaxDB folks. See > http://upstream-berlin.com/2008/09/25/a-couchdb-primer-for-an-activerecord-mindset/ > for a discussion on different Ruby libs. I'm not sure that RelaxDB does this exactly, but... why is it a bad idea? In my case, I suspect that moving "blobs" to the attachments will basically solve my problem, but it seems like you could use different databases in the same way that you'd shard tables in a more traditional setting. What is the normal way of keeping the views in the database in sync with the code? Is there some sort of "migration" concept that loads the new views in, or is it more of a manual procesS? > > Again, no big data-roundtrip problems. See above. With views, you > could do each dimension in a separate query and then intersect the two > results in your application. Or employ a GIS indexer / searcher over > the external indexing interface. But that's not where I want to put my datafiltering logic! And in this case, you'd get a lot of extranious crap -- I don't need to get points of interest from rome if I'm looking for stuff in nyc (same latitude, different world). Where would I find information about the external indexing stuff? > > Cheers > Jan Thanks, -w