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



CouchDB Case Study: Ataxo - Social Media Tracker

New CouchDB case study from Ataxo Social Insider social network monitoring app:

Because CouchDB is fully based on HTTP, they were also able to scale the data store from the start. As Rails developers, they live and breathe HTTP, using ETags and Expires all the time. They knew how to scale HTTP stacks. So they knew they could easily split the server read load just by tying separated CouchDB instances with well understood tools like Nginx or Haproxy and starting replication between them. They could use a dedicated cache such as Squid or Varnish to alleviate the read load in a snap. Most importantly, with a system based on HTTP, every part of the stack is transparent, easy to monitor, enable, disable or multiply.

Actually based on the article, my impression was that they were able to “scale from the start” as they figured out a smart way to split data per customer (update: check Karel’s comment for a clarification on this). Plus using Nginx or Haproxy, Squid or Varnish, doesn’t sound a lot easier than using Memcached + MySQL, or even Membase alone.

Original title and link: CouchDB Case Study: Ataxo - Social Media Tracker (NoSQL databases © myNoSQL)