3 ms·
> He did go into several specifics as to why MongoDB might lose your data. He was talking about that post http://www.korokithakis.net/node/119 http://www.korok
by patrickaljord 16y ago
> He did go into several specifics as to why MongoDB might lose your data.
He was talking about that post http://www.korokithakis.net/node/119 http://www.korokithakis.net/node/119 that doesn't go into any specifics at all.
> Nice jab at CouchDB though!
But couchdb is slow though. I, like many, switched to mongodb because couchdb was just too slow and when I asked in IRC how to make it faster I was told to run a cluster of couchdb, so, not too different than mongodb ;)
- mikealrogers 16y agoit's easy to make something fast if you don't want durability, just look at memcached.
- jchrisa 16y agoFor what it's worth, we've managed to make CouchDB about 10x faster (throughput, not latency) in the last year, and we're just getting started on the optimizations.
- keeto 16y agoCare to share how? I'm really interested in what optimizations you did for this.
- jchrisa 16y agoProbably the biggest one was cutting down on the amount of Erlang message passing that it takes to append a batch of data to the end of the db file. There was also an Erlang configuration change which allowed us to make use of a thread pool for disk-io so that fsyncs didn't block other activity. Really it was a bunch of tiny things, that all added up. The catalyst was the creation and use of a few highly-concurrent benchmark suites that we could use to identify bottlenecks.