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



Some observations on MongoDB & CouchDB

It turns out the reason it was the right choice was that Mongo is quite traditional. It relies on you having a middle tier where your app logic resides. Couch is more radical and it not only replaces the traditional database but also the middle tier. If, as we did on this particular project, you already have a middle tier then using Couch adds complexity to the solution. Some of the app functionality ends up in the mid-tier and some in Couch. With Mongo you keep doing what you were doing. Query result processing and Map Reduce functions are all defined within the Java, Python, etc. code. When we needed a data import script the logic was all in the script and not split between script and database.

But there’s another way to see it: CouchDB keeps data processing code closer to the data — data and code collocation.

Original title and link: Some observations on MongoDB & CouchDB (NoSQL databases © myNoSQL)