Part of the problem is you are storing copies of the documents into
the btree. If the documents are big, it takes longer to compute on
them, and if the results (emit(...)) are big or numerous, then you'll
be spending most of your time in I/O.
My advice is to not emit the document into the view, and if you can,
get the documents smaller in general. If the data can stored as an
binary attachment, then that too will give you a performance
improvement.
-Damien
On Jun 20, 2008, at 4:51 PM, Brad King wrote:
Thanks, yes its currently at 357M and growing!
On Fri, Jun 20, 2008 at 4:49 PM, Chris Anderson <[EMAIL PROTECTED]>
wrote:
Brad,
You can look at
ls -lha /usr/local/var/lib/couchdb/.my-dbname_design/
to see the view size growing...
It won't tell you when it's done but it will give you hope that the
progress is happening.
Chris
On Fri, Jun 20, 2008 at 1:45 PM, Brad King <[EMAIL PROTECTED]> wrote:
I have about 350K documents in a database. typically around 5K
each. I
created and saved a view which simply looks at one field in the
document. I called the view for the first time with a key that
should
only match one document, and its been awaiting a response for
about 45
minutes now.
{
"sku": {
"map": "function(doc) { emit(doc.entityobject.SKU, doc); }"
}
}
Is this typical, or is there some optimizing to be done on either my
view or the server? I'm also running on a VM so this may have some
effects, but smaller databases seem to be performing pretty well.
Insert times to set this up were actually really good I thought, at
4000 to 5000 documents per minute running from my laptop.
--
Chris Anderson
http://jchris.mfdz.com
