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...
-matt
On Aug 8, 2009, at 13:09, Scott Shumaker <[email protected]> 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 (http://www.magnifeast.com), 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<[email protected]>
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
