incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Carlson <lancecarl...@gmail.com>
Subject Re: Considering CouchDB
Date Wed, 20 Nov 2013 16:33:41 GMT
@Diogo Have you considered using cloudant? :)


On Wed, Nov 20, 2013 at 11:01 AM, Robert Newson <rnewson@apache.org> wrote:

> 1) "a stop the world lock when writing to disk"
>
> There's no such thing in couchdb. Databases are append-only, there's a
> single writer, but concurrent PUT/POST requests are faster than serial
> anyway, and each writes to different databases are fully independent.
>
> 2) Stack traces are hard to read, not impossible, but couchdb will
> send useful errors, we don't just dump stack traces (that is, the
> "crash only" thing does not extend to the API)
>
> 3) Compaction can take a long time, sure. Factor it into your planning
> (that is, separate your data into multiple databases along natural
> partitions). The bigcouch merge will add sharding, which divides this
> problem by a configurable factor.
>
> Your two remaining questions are too nebulous to answer but seem to be
> predicated on couchdb being clustered, which it currently isn't.
>
> B.
>
>
>
>
> On 20 November 2013 15:53, Diogo Moitinho de Almeida <diogo149@gmail.com>
> wrote:
> > Hello,
> >
> > Based on the research that I've done, CouchDB seems like a very good fit
> > for the problem I'm trying to solve, but when talking to people from
> within
> > the company, they're expressed that there are some unadvertised down
> sides
> > to it (though they tried using it 3 years ago) and that we would have to
> > migrate fairly quickly off of it.
> >
> > The worries that they expressed were:
> > 1. Scalability (with a stop the world lock when writing to disk).
> > 2. Erlang stack traces not being the easiest to deal with. (I assumed
> with
> > the "crash only" design, that common problems could be solved by
> restarting
> > a node).
> > 3. Garbage collection being a very slow process.
> >
> > And questions that I had were:
> > 1. Would anyone have approximate numbers on how it scales? In terms of
> > writes, size of the data, and cluster size? How big of a cluster have
> > people gotten working without issues? Have people tested this out in the
> > petabyte range?
> > 2. Would anyone have approximate times on how long a map reduce query
> could
> > take (with whatever sized data, I'm just curious)?
> >
> > The use that I'd be looking at is about 200 writes/second of documents
> <50
> > kB each with updates fairly rarely, though if everything goes well, the
> > documents could be a bit larger with a more writes and a lot more
> updates.
> >
> > Thanks in advance for any help,
> > Diogo
>

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