08 March 2011 2 comments Zope
We were already aware of Riak before we started using CouchDB, but we werent sure about trusting a new product at this point, so we decided, after some benchmark, to go for CouchDB.
After the first couple of months, it was obvious that this was a bad choice.
Our main problems with CouchDB is scalability, versionning and stability.
Once we store a document in CouchDB, we modify it at least twice after the original write. Each modification generates a new version of the document. This feature is nice for some use-cases, but we dont need it, and theres no way to disable it, so the size of our databases started to become really important. Youll probably tell me hey, you know you can compact your database ?, and Ill answer sure. The trouble is that we never managed to get it to compact an entire database without crashing (well, to be honest, with the last version of CouchDB we finally managed to compact one database).
The second issue is that one database == one file. When you have multiple small databases, this is fine. When you a have only a few databases, and some grow to more than 1TB, the problems keep growing too (and its a real pain to backup).
We also had a lot of random crashes with CouchDB, even if the last version was quite stable."
Does that sound familiar, fellow Zope developer? I know a lot about ZODB but little about CouchDB. One thing that a lot of people don't know about ZODB is that it's very fast and I think this is true about CouchDB too. Speed isn't the same as a raw speed of inserts/queries because with the concurrency variable added the story gets a lot more complex.
It's the exact same perspectives I've always had on ZODB:
1) It's really convenient and powerful
2) It being a single HUGE file makes it hard to scale
3) Versioning can be nifty but it's often not needed and causes headache with the packing
4) It works great but when it cracks it cracks hard and crypticallyFollow @peterbe on Twitter