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

From CouchDB to Riak at Linkfluence

We were already aware of Riak before we started using CouchDB, but we weren’t 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, versioning and stability.

I am wondering how using BigCouch would have addressed Linkfluence requirements:

and the stability/maintenance issues.

The article also gives an overview of Linkfluence polyglot persistence architecture:

  • PostgreSQL: some indexes on documents’ ID
  • MongoDB: store tweets relationships and some indexes
  • CouchDB Riak for content and metadata
  • Redis for caching
  • Solr for search indexes
  • ElasticSearch for secondary indexes

You might also enjoy some of the comments on the Hacker News thread.

Original title and link: From CouchDB to Riak at Linkfluence (NoSQL databases © myNoSQL)

via: http://labs.linkfluence.net/nosql/2011/03/07/moving_from_couchdb_to_riak.html