We are running CouchDB as a replacemant for MySQL for our shops (70.0000 items/shop, a total of 4 million attributes of all items, cross connections between items).
Our goals were:
Easy replication from a master-db to several clients with different documents.
Fast pre-calculated data like "how many parts do I have with this attribute and that filter, fitting to those conditions"
facts:
- Our shops are now running much faster than with MySQL (and mysql-database needed additionaly 1-3 days of pre-calculating (so updating was twice a month), making the data ready for product counting and filtering, CouchDB needs 5 hours, so we could update product data every night)
- Setting up (filtered) data distribution & backups to the shop nodes is fast and easy
but also:
- Understanding map/reduce and the limits of not having joins is quite hard
- No operation on data like "delete where" or "update where" without external programs
- Replication works well, unless there is a problem; then it's really hard to find out what was the reason (for beginners)
- The installation of CouchDB without binaries (yes there are a some in the wild, but not for every OS/version) could be hard, if you are not a Linux geek. But the CouchDB Community is helpful (#couchdb), and luckily there are companies out there (cloudant, iriscouch) that offer services from free to big business.
- CouchDB is moving forward, so there are a lot of changes (improvements) going on that might change they way you work. But basic things remain stable.
As a result:
MySQL as a database for data creation and maintaining is reliable and easy to understand and handle. I think we will not change this.
But I also don't want to miss the power of CouchDB views and the ease of replication setup.
Production couches sometimes caused trouble after months of work due to misconfiguration and forgotten logrotates (view building takes too long or hangs, replication stops), but never lost data, and always could be easily reset.