couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Copenhaver <>
Subject Re: Production usage of BigCouch and the Future?
Date Wed, 15 Aug 2012 13:00:09 GMT
Excuse me for butting in a bit, but I wanted to point out that real-time is
about consistent performance not raw speed. Also CouchDB doesn't do any
caching itself. It relies on the filesystem for everything (at least I
believe this is still true). Of course the filesystem will cache things for
you and Erlang is quite capable of handling concurrent IO and connections.
Erlang on a single request performance might not be as fast as other
systems, but usually at scale Erlang does quite well.

So CouchDB will probably handle it fine honestly that is once built. That
much data will take some time to build the views the first time. Having
your views in multiple design documents could help... especially if you
have to update only one of them at some other time.

Now if the read performance is adequate for your needs, you'll have to

On Wed, Aug 15, 2012 at 8:48 AM, JRad <> wrote:

> Robert,
> Can it handle a 150G view on a Xeon x4 2.6, with 64G memory with 15k disks,
> without performance degradation? we need couchdb's realtime view reponse on
> 30 concurrent connections!
> I don't know details of paging for b+tree in couchdb, but can we achieve a
> (view_size) / (memory) ratio that is performance-safe!? ( this may mean it
> leads to cover top most levels of b+tree in memory!? ) we estimate about 1
> billion keys in that 150G!

“The limits of language are the limits of one's world. “ - Ludwig von

"Water is fluid, soft and yielding. But water will wear away rock, which is
rigid and cannot yield. As a rule, whatever is fluid, soft and yielding
will overcome whatever is rigid and hard. This is another paradox: what is
soft is strong." - Lao-Tzu

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message