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 <diogo...@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
