Hey all
I went to jchris' talk at columbia a week or so ago, and have been
playing around with couchdb every since. I'm not sure that I like all
of the high level design decisions (i for one like types, and I think
I'm running in this below) but I wanted to actually use it because
there certainly are some neat things. I have a couple of newbie usage
questions.
The scenario is that I'm building a spider-type thing and going to be
processing the "remote resource" into a specific localized "document".
So I'm going to be pulling in say 3 pages and from that going to
produce both a document that describes the resteraunt, has it's menu
and reviews, knows it's lat and long and going to serve them up on a
map. I'm following the architecture that I described
in http://benchcoach.com/papers/scraping and am basically
reimplementing menumaps as a proof of concept with couchdb.
I'm using merb and relaxdb at the moment, but I think I may need to get
a little lower level.
Question 1: Where do I store the original documents?
Right now I have a "RemoteUrl" document which contains the
last-modified, etag, encoding, and the content itself. (Its very
important in the design that I keep the original content and all
previous versions around.) For some reason, I can't store the content
directly -- I need to base64 encode it, which seems like a problem with
the ruby json library. But couchbd is slow when it has all of these
200K documents sitting around in it. Is this not the right sort of
usage? I've created a map/reduce view for the "latest revision" like
this:
function(doc) {
if( doc.class == "RemoteUrl" && doc.content ) {
emit(doc.normalized_url, doc );
}
}
function(key,values,rereduce) {
if(rereduce) {
return values;
} else {
var max = values[0].created_at;
var doc = values[0];
for( i = 0; i < values.length; i++ ) {
if( values[i].created_at > max ) {
doc = values[i]; max=values[i].created_at;
}
}
}
return doc;
}
but it takes a long time to run and see. But this is probably because
it actually needs to load up all the data, send it over a pipe to the
javascript process, have it do it, send it back, and repeat the process
with the reduce step. Its pretty slow. Is there a better way to do
this? My guess is that if I make this into two queries, and don't emit
the doc.content (the actually content of the file) that it would be a
lot faster, but that seems pretty ugly. I.e. just map
[doc._id,doc.created_at] and then make another trip to pull back the
id. But you still have the problem of view creation taking forever.
Does anyone have any suggestions?
Question 2: I'm using RelaxDB right now, and it only really wants to
work for one database per environment. Seeing as how slow couchbd
processing these documents, I was thinking that I'd want to keep the
bulk-data stuff in it's own database so that the other views won't need
to process over the whole data set. The views really work by document
"type", so there's no need to pump the huge amount of data from the
erlang process to the javascript process when all it's doing is seeing
that doc.class != "RemoteUrl". (Which is why I'd want to have types,
but no matter, I guess we can hack them on the side like this!) I'm
guessing that's why it's falling down. So if I could spit out the
"web-cache" database from "parsed" database I think it would be a
little faster. I'm wonder what people think about this sort of design
decision, and how they would suggest implementing it.
Question 3: Say I eventually get something which has 2 floating point
attributes. (e.g. lat and long.) How would I get all of the documents
where those were in a square? i.e.
select * from places where places.lat >= left_lat and places.lat <=
right_lat and places.longitude >= top_longitude and places <=
bottom_longitude;
I can see how'd you'd do this with one dimension, but I'm not sure how
you'd do it with the second. Especially since you need to make all
these data round trips...
Thanks in advance. I think there are a lot of very interesting ideas
in Couchdb. It seems like a lot of this stuff can't be don't nearly as
well as with a sql database, but I'm hoping that it's just me being
ignorant.
-w
http://sublimeguile.com