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



Memory Usage in Couchbase 2.0

The following fragment from Shawn Chiao’s post about what he sees as drawbacks in using Couchbase as the backend for free-to-play games made me really curious about the memory requirements in Couchbase 2.0:

The Couchbase cluster need to keep the metadata of every single key in memory, even if those values are not in the working set.

According to the Couchbase 2.0 manual (pdf) page 59:

The goal is to size the RAM available to Couchbase so that all your document IDs, the document ID meta data, along with the working set values fit into memory in your cluster, just below the point at which Couchbase will start evicting values to disk (the High Water Mark).

The above doesn’t read as a strong requirement. Just as good practice recommendation. But on the next page, under the “Meta data per document (metadata_per_document) setting” I read:

This is the space that Couchbase needs to keep metadata per document. It is 120 bytes. All the documents and their metadata need to live in memory at all times.

Plus on page 60:

total_metadata: (documents_num) * (metadata_per_document + ID_size) * (no_of_copies)

All the documents need to live in the memory.

I read this as a confirmation of the strong requirement that all the keys and their metadata must fit in memory.

Original title and link: Memory Usage in Couchbase 2.0 (NoSQL database©myNoSQL)