couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt King <>
Subject Re: How Views Work
Date Sun, 09 Aug 2009 00:17:59 GMT
This approach does make a lot of sense, I'll see how something like  
this would work. It doesn't seem like having extra items in the list  
would hurt much.

I did slightly alter my view calculation to only emit if the location  
was in a specified distance from the center point, and ditching the  
start/end key idea. Then I guess I could create a view for each center/ 
range combo as it is requested, maybe by naming the view a hash of  
those two identifiers. My only concern then is the latency of checking  
if the view exists, then creating it if it doesn't. Also, since my app  
allows searching for any location in the world for points, there could  
be a pile of one-off views laying around that rarely gets used again.

Thanks for the tips, keep em coming. I'll report back ny findings...


On Aug 8, 2009, at 13:09, Scott Shumaker <> wrote:

> As you've observed, this does make geo calculations in this manner
> inefficient.  However, you just have to think about the problem
> differently.  Instead, you can set up an artificial grid (of say 1
> mile squares), and for each location, emit as the key which grid cell
> it lies in.  Then, when you're looking for a center point, you find
> which grid cell it lies in, and query accordingly.  For a 1 mile
> radius, you might ask for the cell containing the center point itself
> and 4 of it's neighbors (using multi-key fetch).  For 2 miles, you
> might ask for 16 cells  (4x4 cells).
> This will give you approximate results - it will always include all of
> the locations, but will include some extra locations as well.  So you
> just need to filter them down at this point, in the client-side (or
> somewhere else in your backend).
> For our application (, we didn't use CouchDB
> for the geo search directly - we do the bucketing in a separate search
> server that pulls documents from Couch using all_docs_by_seq.  But
> that's because we have to search on a lot of different criteria, and
> that would create an explosion of different views for all of the
> combinations and sorting options (not to mention the difficulty of
> merging / combining the output of multiple views).
> On Sat, Aug 8, 2009 at 10:06 AM, Adam Kocoloski<>  
> wrote:
>> On Aug 7, 2009, at 1:35 PM, Matt King wrote:
>>> Hi all,
>>> I have question about how views work. I read that when you create  
>>> a view,
>>> CouchDB indexes it so it's faster on the next request. But if I  
>>> pass in
>>> startkey and endkey, does it only index the docs that are  
>>> returned? Or is
>>> the entire list indexed and CouchDB returns the offsets as  
>>> requested?
>> Hi Matt, each time a view is queried CouchDB indexes all the  
>> documents that
>> have changed since the last query and then returns the updated  
>> result.
>>  Query-string parameters like startkey and endkey don't affect this  
>> behavior
>> (in fact, if you think about we _can't_ filter the list of docs to be
>> indexed based on those parameters, since we don't know a priori  
>> what keys
>> will be emitted by a map over a given document).
>> Best, Adam

View raw message