Over the weekend, I was experimenting with CouchDB to see if it can pass the C10K barrier. Some of the performance optimizations I made along the way are really OS-level optimizations that affect MochiWeb (erlang web server) and fairly well documented in many blogs. This one by @metabrew in particular is a pretty good read, since it focuses on Erlang and MochiWeb. While I am a performance junkie, I am not an Erlang hacker. So this is a call for help to the CouchDB hackers for recommendations on scaling out CouchDB.

The initial tweaks made by the blitz.io guys, took CouchDB from under 1000 concurrent users to around 2300 concurrent users. There’s still a long way to 10k concurrent users and they’d appreciate your help.

Original title and link: Help CouchDB Break the C10K Barrier (NoSQL database©myNoSQL)

via: http://blog.mudynamics.com/2011/09/05/help-couchdb-break-the-c10k-barrier/

That’s the gist of this application. It is non-trivial and had a very rich design and interaction. My team had an excellent QA, excellent front end dev, and me who was the only one who knew MarkLogic. The other team chose to implement theirs using a Javascript front-end architecture communicating with CouchDB (later Java with MongoDB) on the backend. The two teams involved very skilled people. If these two technology approaches were going to go head-to-head, these were the people to do it.

Judging by the brief description of the requirements, there was nothing about this application that either CouchDB or MongoDB would not be able to handle. So I assume that there was some learning curve involved in the team that went first with CouchDB and then moved to MongoDB. Not to mention changing the technology for such a short term project.

Original title and link: 1 Week, 1 Project, 3 Databases: MarkLogic, CouchDB, MongoDB (NoSQL database©myNoSQL)

via: http://xquerywebappdev.wordpress.com/2011/08/20/marklogic-decidedly-wins-development-competition/

Nuno Job’s NanoCouch Node.js driver for CouchDB:

After doing development like this for a while some obvious patterns started to emerge, as well as some code duplication. So the idea of nano was born: Build the minimal abstraction possible that allows you to use CouchDB from nodejs while preserving stream#pipe capabilities.

NanoCouch was well received by the CouchDB community with comments like:

Mikeal Rogers: this post is really good because it doesn’t assume you know all the little things i always forget to explain, like how the callback arguments are structured. perfect beginner article! :)

Joe McCann: This is why CouchDB and Node.js are made for each other

Original title and link: Minimalistic CouchDB Client for node.js (NoSQL database©myNoSQL)

via: http://writings.nunojob.com/2011/08/nano-minimalistic-couchdb-client-for-nodejs.html

Bradley Holt:

I’ve found CouchDB to be a great fit for domain-driven design (DDD). Specifically, CouchDB fits very well with the building block patterns and practices found within DDD. Two of these building blocks include Entities and Value Objects. Entities are objects defined by a thread of continuity and identity. A Value Object is an object that describes some characteristic or attribute but carries no concept of identity. Value objects should be treated as immutable.

Aggregates are groupings of associated Entities and Value Objects. Within an Aggregate, one member is designated as the Aggregate Root. External references are limited to only the Aggregate Root. Aggregates should follow transaction, distribution, and concurrency boundaries. Guess what else is defined by transaction, distribution, and concurrency boundaries? That’s right, JSON documents in CouchDB.

The way I read this is the impedance mismatch between the object model and the document-based model is lower than what we’ve seen in object-relational world.

Original title and link: CouchDB and DDD (NoSQL database©myNoSQL)

via: http://bradley-holt.com/2011/08/couchdb-and-domain-driven-design/

Geeky:

The programmer writes an OCaml application that exports one or more map and reduce functions using the API found in module CouchAdapter, and creates a CouchDB design document that specifies the application path and the name of the exported functions. The adapter server then receives evaluation requests from CouchDB and passes them to the application, and returns the result back to CouchDB.

The overall architecture:

Original title and link: Using OCaml From CouchDB Views (NoSQL database©myNoSQL)

via: http://www.nicollet.net/2011/08/using-ocaml-from-couchdb-views/

Knowing the strenghts and weaknesses of each of them could help making a decision. But do not fall for comparing them:

I’ve compiled a simpler item-by-item comparison of CouchDB and Redis, and it appears to be that CouchDB is strong precisely where Redis is weak (storing large amounts of rarely-changing but heavily indexed data), and Redis is strong precisely where CouchDB is weak (storing moderate amounts of fast-changing data).

Original title and link: CouchDB and Redis: Strengths and Weaknesses (NoSQL database©myNoSQL)

via: http://ai.mee.nu/is_couchdb_the_anti-redis

blitz.io, the winner of the Best CouchDB app:

CouchDB is the backbone of blitz.io. After some experimentation with various hosted CouchDB’s, we ended up running our own cluster across the virginia and california regions of AWS with multi-master replication between the two regions. We use m1.Large instances and are currently running 1.1.0 though for a while we had both 1.0.2 and 1.1.0 together with a 4-way replication during the upgrade process.

[…]

The multi-region deployment is unique because it minimizes the geo latencies to the scale engines described below. Besides this also gives us redundancy, and distributed writes, though at this point in the life of blitz.io we don’t currently shard.

Here is also their Prezi presentation:

via: http://blog.mudynamics.com/2011/08/07/blitz-io-how-we-use-heroku-aws-and-couchdb/

The architecture of blitz.io, a geo-distributed load and performance testing service built on top of the CouchDB:

blitz.io uses regional CouchDB clusters as the backbone with the scale engines using continuous _changes waiting for things to do.

blitz.io architecture demonstrates some of the most interesting features in CouchDB:

• multi-master replication
• filtered _changes
• conflict resolution

Original title and link: blitz.io: Best CouchDB App (NoSQL database©myNoSQL)

via: http://blog.mudynamics.com/2011/08/01/blitz-io-wins-the-best-couchdb-app-at-couchconf/

Bradley Holt^[1]:

Streamlining of your codebase (no middle tier), replication, the ability to deploy/replicate an application along with its data, and the side benefits that come with going “with the grain” of how the web works are some of the benefits of building CouchApps.

The interview mentions also the potential of using CouchDB on Android and iOS platforms. CouchOne released back in September CouchDB for Android and then 6 months later—and after the merger with Membase—iOS Mobile Couchbase.

Original title and link: What Are the Benefits of Building CouchApps? (NoSQL database©myNoSQL)

via: http://radar.oreilly.com/2011/06/couchdb-couchapps-html5-mobile.html

Neat idea that could prove pretty useful in development environments:

CQS is a message queue system, using Apache CouchDB. It is exactly like Amazon Simple Queue Service (SQS). The API is the same. Everything is exactly the same, it just runs on CouchDB.

Original title and link: CouchDB Queue Service: Amazon SQS API-compatible (NoSQL database©myNoSQL)

via: https://github.com/iriscouch/cqs