ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Mozilla Raindrop and CouchDB

After mentioning Mozilla Raindrop as a CouchDB case study and using it in an informed comparison of CouchDB and MongoDB, I’m filing this one under lessons learned:

  • CouchDB isn’t central to this architecture, but that’s probably good for Couch’s reputation — we were misusing it, and causing it to behave poorly. We still think it’s awesome, we just weren’t able to make it work for this use case (lots of writes & reads, only per-user data).
  • Specifically, we fell prey to the “ooh, shiny hammer!” effect, and used CouchDB for everything, including storage of temporary variables, as a message queue, and as a state machine of sorts. Given that our ability to understand the performance implications of some of these design decisions is limited, we’re stepping back from innovating on the back-end architecture, and “falling back” to a system that we can profile and optimize more easily.

via: http://groups.google.com/group/raindrop/browse_thread/thread/7486e1697aef522a/c8c59f07d16c534a