CouchDB: "Very, very, very slow"?

[Sven Helmberger <sv...@gmx.de>]

Hi!

I just stumbled over some presentation via twitter

http://github.com/igal/ruby_datastores/raw/master/2009-11-14%20Non-relational%20data%20stores%20for%20OpenSQL%20Camp.pdf 


What's your opinion on it?

Is CouchDB really that slow?
Are the test unfair (no concurrency, no caching)?

Regards,
Sven Helmberger

Re: CouchDB: "Very, very, very slow"?

[Paul Davis <pa...@gmail.com>]

On Wed, Nov 18, 2009 at 4:03 PM, Sven Helmberger <sv...@gmx.de> wrote:
> Hi!
>
> I just stumbled over some presentation via twitter
>
> http://github.com/igal/ruby_datastores/raw/master/2009-11-14%20Non-relational%20data%20stores%20for%20OpenSQL%20Camp.pdf
>
> What's your opinion on it?
>
> Is CouchDB really that slow?
> Are the test unfair (no concurrency, no caching)?
>
> Regards,
> Sven Helmberger
>

Its not a matter of fairness. A test load that CouchDB is good at
might not be good for a different database. There have been a couple
pushes to have a set of benchmarks that could be run to get an overall
feel for a given database but there's a lot of other hidden aspects.
As Chris points out a fairly specific one is disaster recovery.

http://jan.prima.de/plok/archives/175-Benchmarks-You-are-Doing-it-Wrong.html
http://vmx.cx/cgi-bin/blog/index.cgi/benchmarking-is-not-easy%3A2009-09-23%3Aen%2CCouchDB%2CPython%2CTileCache%2Cgeo
http://img.skitch.com/20090724-kyn5f1wn59wqmxng5d2dadipi3.jpg

Paul Davis

Re: CouchDB: "Very, very, very slow"?

[Chris Anderson <jc...@apache.org>]

On Wed, Nov 18, 2009 at 1:03 PM, Sven Helmberger <sv...@gmx.de> wrote:
> Hi!
>
> I just stumbled over some presentation via twitter
>
> http://github.com/igal/ruby_datastores/raw/master/2009-11-14%20Non-relational%20data%20stores%20for%20OpenSQL%20Camp.pdf
>
> What's your opinion on it?

Igal followed benchmarks from my Performance chapter in the CouchDB
Definitive Guide:

http://books.couchdb.org/relax/reference/high-performance

Only he chose the "worst-case scenario" benchmark (a single serialized
writer). CouchDB is designed for many concurrent clients, each
applying their own mix of reads and writes. Eg: web traffic.

If CouchDB can do 500 ops/second on your box with a single serialized
client, it should be able to maintain that rate for hundreds of
simultaneous clients. So you can count on applications that are snappy
on Couch for a few users to stay snappy even as the number of
concurrent users goes up.

Because CouchDB is tuned for concurrency, we ensure that performance
degrades gracefully as load is increased.

And because we have a robust append-only storage format, if you lose a
server under load, when you bring it back up, it will be consistent
and ready to go immediately, with no fixup phase.

Hope that helps,

Chris

>
> Is CouchDB really that slow?
> Are the test unfair (no concurrency, no caching)?
>
> Regards,
> Sven Helmberger
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io