Re: Write performance vs. query performance

[Bradford Winfrey <br...@yahoo.com>]

Well, the first big plus is that it's non-blocking.  So as people are reading, they won't be hung up while the writes finish.  Having said that things that are being written while someone is reading won't be immediately available in said reads (but will be available for any which take place there after as long as the update=false parameter isn't specified).

As I've used it, I can say that I've been quite pleased with it's responsiveness while many reads and writes are being executed simultaneously.  Keep in mind though that each document upon creation is indexed as it's written, so depending on your views, your mileage may vary.

All, correct me where appropriate if I've mislead this guy...

Brad




________________________________
From: Jonathan Ginter <jo...@coradiant.com>
To: couchdb-user@incubator.apache.org
Sent: Friday, October 31, 2008 4:10:03 PM
Subject: Write performance vs. query performance

I am curious about the performance of CouchDB for write-intensive
applications.  Our application typically writes in the tens of millions
of records (in this case, documents) per day.  Would CouchDB be able to
handle that kind of load while still being responsive to queries?  Is it
only a matter of scaling up the deployed hardware to solve that problem?



Thanks.



Jonathan


      

Re: Write performance vs. query performance

[Jan Lehnardt <ja...@apache.org>]

On Nov 4, 2008, at 17:07, Bradford Winfrey wrote:

> Well, the first big plus is that it's non-blocking.  So as people  
> are reading, they won't be hung up while the writes finish.  Having  
> said that things that are being written while someone is reading  
> won't be immediately available in said reads (but will be available  
> for any which take place there after as long as the update=false  
> parameter isn't specified).

Every write will be available at the time said write is reported to be  
complete. If there is a read operation that started before the write  
finished, it will not know about the write. And it shouldn't :)

> As I've used it, I can say that I've been quite pleased with it's  
> responsiveness while many reads and writes are being executed  
> simultaneously.  Keep in mind though that each document upon  
> creation is indexed as it's written, so depending on your views,  
> your mileage may vary.

Actually, documents are not indexed upon creation. View indexes are  
build (i.e. indexing docs happens) on querying a view. Dirty reads are  
possible with the update=false parameter. You can have as many views  
as you want without having write-speed degrade.

Cheers
Jan
--