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



Couchbase: All content tagged as Couchbase in NoSQL databases and polyglot persistence

Using Riak as Cache Layer

Sean Cribbs explains how to use Riak as a caching solution:

  1. Bitcask or Memory backends
  2. The possibility of configuring the cluster for lower guarantees of per-key availability

Then benchmark the system for your scenario.

Original title and link: Using Riak as Cache Layer (NoSQL database©myNoSQL)


The Story of Scaling Draw Something From an Amazon S3 Custom Key-Value Service to Using Couchbase

This is the story of scaling Draw Something told by its CTO Jason Pearlman.

The early days, a custom key-value service built on top of Amazon S3:

The original backend for Draw Something was designed as a simple key/value store with versioning. The service was built into our existing ruby API (using the merb framework and thin web server). Our initial idea was why not use our existing API for all the stuff we’ve done before, like users, signup/login, virtual currency, inventory; and write some new key/value stuff for Draw Something? Since we design for scale, we initially chose Amazon S3 as our data store for all this key/value data. The idea behind this was why not sacrifice some latency but gain unlimited scalability and storage.

Then the early signs of growth and the same key-value service using a different Ruby stack:

Being always interested in the latest tech out there, we were looking at Ruby 1.9, fibers, and in particular Event Machine + synchrony for a while. Combined with the need for a solution ASAP - this lead us to Goliath, a non-blocking ruby app server written by the guys at PostRank. Over the next 24 hours I ported over the key/value code and other supporting libraries, wrote a few tests and we launched the service live. The result was great. We went from 115 app instances on over six servers to just 15 app instances.

The custom built key-value service didn’t last long though and the switch to a real key-value store was made:

We brought up a small cluster of Membase (a.k.a Couchbase) rewrote the entire app, and deployed it live at 3 a.m. that same night. Instantly, our cloud datastore issues slowed down, although we still relied on it to do a lazy migration of data to our new Couchbase cluster.

Finally, learning to scale, tune and operate Couchbase at scale:

Even with the issues we were having with Couchbase, we decided it was too much of a risk to move off our current infrastructure and go with something completely different. At this point, Draw Something was being played by 3-4 million players each day. We contacted Couchbase, got some advice, which really was to expand our clusters, eventually to really beefy machines with SSD hard drives and tons of ram. We did this, made multiple clusters, and sharded between them for even more scalability over the next few days. We were also continuing to improve and scale all of our backend services, as traffic continued to skyrocket. We were now averaging hundreds of drawings per second.

Scaling “Draw something” is a success story. But looking at the above steps and considering how fast things had to change and evolve, think how many could have stumbled at each of these phases, think what would have meant to not be able to tell which parts of the system had to change or to have to take the system offline for upgrading parts of it.

Original title and link: The Story of Scaling Draw Something From an Amazon S3 Custom Key-Value Service to Using Couchbase (NoSQL database©myNoSQL)


Couchbase at OMGPOP: Some Clarifications

When I first read the OMGPOP story I wrote the Two Sides of the OMGPOP Cloud and Couchbase Scalability Story. Then came a long conversation with James Phillips of Couchbase. Now we have a better picture of Couchbase’s involvement in OMGPOP scaling success story:

We became aware of our role in their success when they called us to ensure they were employing best practices in planning for growth of their database cluster. As the number of users, games, and drawings grew at an unprecedented rate, they were able to continuously add capacity to the cluster (growing to over 100 servers), while maintaining application performance and with zero application downtime. There was never a performance drop or a single moment when new players couldn’t join the party – even in the face of dying hardware! At one point, a motherboard issue with their selected hardware was taking cluster members down at a frightening pace. Couchbase took even those failures in stride without interrupting game operation or performance.

For the future I hope Couchbase people will remember James Phillips’ promise. Time to moving on now.

Original title and link: Couchbase at OMGPOP: Some Clarifications (NoSQL database©myNoSQL)

Two Sides of the OMGPOP Cloud and Couchbase Scalability Story

Many media sites published on Friday the PR release of OMGPOP growth story citing the usage of cloud services and Couchbase as their scaling solution (GigaOm, BusinessInsider).

When reading it, I’ve jotted down:

  1. The good: using a combination of cloud and a NoSQL database (Couchbase) allowed OMGPOP to scale
  2. The bad: OMGPOP had to call in people from Couchbase to help out with scaling

Question is if you can throw in more iron and hire experts wouldn’t many other database solutions be able to cope with OMGPOP’s growth?

Original title and link: Two Sides of the OMGPOP Cloud and Couchbase Scalability Story (NoSQL database©myNoSQL)

Big Data Investment Network Map

Very interesting visualization of some of the companies in the Big Data market connected through their venture capital and investment firms by Benedikt Koehler and Joerg Blumtritt over Beautiful Data blog:

Big Data Investment Network Map

Click to see larger size

There’s only one company I couldn’t find on this map: Hortonworks.

Original title and link: Big Data Investment Network Map (NoSQL database©myNoSQL)

The Couchbase Genealogy

Looks like Matthew Aslett (the451group) had his own version of the Couchbase genealogy:

Couchbase genealogy

Credit Matt Aslett .

Original title and link: The Couchbase Genealogy (NoSQL database©myNoSQL)

NoSQL Market from Couchbase Perspective

James Philips (Couchbase) for Curt Monash:

  • MongoDB is the big competition. He believes Couchbase has an excellent win rate vs. 10gen for actual paying accounts.
  • DataStax/Cassandra wins over Couchbase only when multi-data-center capability is important. Naturally, multi-data-center capability is planned for Couchbase. (Indeed, that’s one of the benefits of swapping in CouchDB at the back end.)
  • Redis has “dropped off the radar”, presumably because there’s no particular persistence strategy for it.
  • Riak doesn’t show up much.

I assume this is sort of a pre-sales/sales department 100k feet overview.

Original title and link: NoSQL Market from Couchbase Perspective (NoSQL database©myNoSQL)


History of Couch Projects

Just in case you thought someone made up the whole thing about the status of CouchDB being confusing:

History of Couch Projects

Found in Koji Kawamura‘s Introduction of CouchDB JP slides .

On the other hand I’m still trying to figure out if things in CouchDB land were more confusing than the various Hadoop versions out there. If you compare the two genealogy trees you’ll notice a reversed pattern.

Original title and link: History of Couch Projects (NoSQL database©myNoSQL)

Couchbase Server 1.8 Released, Rebranding and Some Improvements in Cluster Rebalancing

Couchbase Server 1.8 replaces Membase Server 1.7 as our “flagship” database offering. In addition to the obvious rebranding, we’ve made substantial improvements in the cluster rebalancing process and fixed a number of nagging issues in 1.7.

In case you feel lost with which Couchbase products are which, read my 5 bullet points explanation.

Original title and link: Couchbase Server 1.8 Released, Rebranding and Some Improvements in Cluster Rebalancing (NoSQL database©myNoSQL)


Couchbase: Clarifying Confusions in 5 Bullet Points

Here are the 5 bullet points that would helped Couchbase clarify all the confusion about Couchbase, Membase, CouchDB:

  1. We are working on Couchbase server 2.0. This is our next major release and the only product we will be focusing next. It represents the continuation of our current Membase server product.
  2. Until Couchbase server 2.0 is out, we might release one or two updates to our Membase server that are addressing the most important issues.
  3. We will provide a migration path to users of Membase server to Couchbase server 2.0
  4. We will not support anymore our distribution of CouchDB known as Couchbase Single Server. Damien Katz, creator of CouchDB, has decided to step away from the Apache CouchDB project and focus on Couchbase development.
  5. Due to the major changes in Couchbase server 2.0, we will not offer a migration path for the users of Couchbase Single Server to Couchbase server 2.0.

Original title and link: Couchbase: Clarifying Confusions in 5 Bullet Points (NoSQL database©myNoSQL)

Reinforcing Couchbase's Commitment to Open Source

Bob Wiederhol, the CEO of Couchbase:

We’re 100% committed to open source and all of our code is available under the Apache 2.0 license.


Original title and link: Reinforcing Couchbase’s Commitment to Open Source (NoSQL database©myNoSQL)


CouchDB: A Season Finale

There was a story earlier this year that I, as someone that has spent an enormous amount of time contributing to open source projects, thought it was no story. Considering how much was published about it, chances were you already read something about Damien Katz’s The future of CouchDB.

At the time of that post, my draft looked like this:

And now I, and the Couchbase team, are mostly moving on. It’s not that we think CouchDB isn’t awesome. It’s that we are creating the successor to it: Couchbase Server. A product and project with similar capabilities and goals, but more faster, more scalable, more customer and developer focused. And definitely not part of Apache.

Elvis has left the building. Please welcome The Beatles!

I always thought that some sort of a message from the its creator was needed to completely clear the waters about CouchDB. Damien’s post together with the earlier post from Couchbase announcing the discontinuation of the Couchbase Single Server (Couchbase’s CouchDB distribution) were bringing closure to the CouchDB saga. And that was good.

I knew that the Apache CouchDB project and community are doing fine. Noah Slater’s email just confirmed that:

As some of you may have already read, Damien Katz, Apache CouchDB’s original developer, has publicly announced that he intends to focus his time exclusively on developing other products for his company. Damien has had very little involvement in the CouchDB project for a year or more now, so, for many people, this is confirmation of what they already knew. […]

Our biggest strength has always been the breadth and depth of our community of developers and users. In the very near future, we’ll be voting in a new committer, appointing a new PMC member, sprucing up the website, and making a major new release

Late last year, I also suggested that Cloudant would become the go to company for CouchDB. Adam Kocoloski’s post confirmed this too:

We, along with a host of other companies, strongly support the open source community in building CouchDB and we do not plan on stopping. We have been fortunate in our ability to attract outstanding engineers, investors, and customers. We intend to continue devoting resources to Apache CouchDB and offer our help in any way the community desires.

While I could understand some of the criticisms[1], my conclusion was pretty close to what Bradley Holt wrote:

Going forward, you’ll have two choices, either Apache CouchDB or Couchbase Server. The road map for Apache CouchDB will continue to be determined by community consensus. The road map for Couchbase Server will be determined by Couchbase, the company.

But I was left with a nagging feeling that I missed something. I kept on circling around a small part of the original post:

What’s the future of CouchDB? It’s Couchbase.

How could a product that is removing defining features (e.g. the HTTP RESTful API or the peer-to-peer replication), that is already different (Volker Mische’s post provides details), and that offers no clear migration path be the future of CouchDB?

The answer is actually simpler than I thought:

Couchbase is the future of CouchDB as CouchDB was the future of Lotus Notes. A new product that takes inspiration from the experience and lessons learned while building the previous one.

And that was a CouchDB season finale. I’m already looking forward to the next season’s plots.

Original title and link: CouchDB: A Season Finale (NoSQL database©myNoSQL)