Real World NoSQL: Membase at Tribal Crossing


Edit Note: This is the fifth and final article of a multi-part series of posts exploring the use cases for NoSQL deployments in the real world. So far, the series has covered case studies on MongoDB, Cassandra, Amazon’s Simple DB and Hbase.

With all the excitement surrounding the relatively recent wave of non-relational – otherwise known as “NoSQL” – databases, it can be hard to separate the hype from the reality. There’s a lot of talk, but how much NoSQL action is there in the real world? In this series, we’ll take a look at some real-world NoSQL deployments.

Tribal Crossing develops online social games such as “Animal Party.” Although games like Animal Party are embedded in Facebook, the Tribal Crossing’s game servers are hosted in the Amazon EC2 ( amzn) cloud. Like most social games, Tribal Crossing applications have a very high database write rate – changes to the game state need to be stored so the user doesn’t lose her game score, “loot” or location. Tribal Crossing migrated from MySQL to Membase with the aim of supporting a higher write rate: it expected to support about 10 times the write load compared to what is possible with MySQL.

The Membase database system is based on the widely used Memcached distributed object cache. Many websites use Memcached in conjunction with MySQL; Memcached keeps copies of frequently used data in a memory cache distributed across a cluster of machines, and the application can reduce the load on MySQL by reading from this cache. Membase presents a Memcache-compatible interface, but adds persistent storage for the cached objects, effectively replacing MySQL as the disk storage engine. Applications can therefore, in theory, replace both MySQL and Memcached with Membase through relatively minor changes to application code.

Tribal Crossing wanted to focus on game design rather than database management, and so sought a solution that would scale in line with user demand without manual intervention. Membase’s transparent scaling – which allows Tribal Crossing to increase capacity quickly and easily by adding more nodes to the Membase cluster — helps Tribal Crossing adapt to boosts in game traffic when games “go viral” on Facebook.

As with many migrations from relational to non-relational database, the application needed to accept responsibility for many of the services traditionally provided by the RDBMS. For instance, Tribal Crossing had to implement their own locking system — the application stores lock information explicitly in Membase, rather than letting the database automatically manage concurrency.

As a pure key-value store, Membase doesn’t enforce a specific schema; the application can store any “value” it likes against a specific key. As is typical in key-value stores, the value stored is closely related to program objects used in the application code. This simplifies the interactions between the application and the database, since the usual object-relational mapping (OPM) isn’t necessary. Tribal Crossing also appreciated the ability to modify the schema as required by the application without having to issue time-consuming “alter table” statements. However, this “schema-less” architecture renders the database less suitable for ad-hoc analysis and data-mining; data for business analysis is currently written out to a separate (MongoDB) database.

“So far, we are pretty happy with what Membase has provided us,” says Shawn Chiao, co-founder of Tribal Crossing. “We did have some hiccups in our production environment from being an early adopter, but the Membase folks have been very helpful in troubleshooting and providing updates to address issues that came up.”


After covering these five use case,s the main conclusion one can draw about NoSQL in real-world settings is that extreme claims about the demise of the relational database are exaggerated. The real-world practitioners I’ve talked with have chosen a NoSQL database as the best database tool for specific application goals. For most, a desire to achieve higher levels of application scalability lead to a decision to sacrifice relational database features. Many of these implementations are in their early stages, and some are yet to be fully proven.

We’re bound to hear more stories – both positive and negative – as these and other projects roll out. What seems certain is that more companies will examine non-relational alternatives, and that these alternatives will mature and increasingly offer valid alternatives to the RDBMS for some types of applications, especially those operating at high scale.

To learn more about the factors driving big data and optimal strategies for solving it, including from Hadoop, NoSQL and MPP database leaders, come to our Big Data conference held on March 23 in NYC.

Guy Harrison is a director of research and development at Quest Software, and has over 20 years of experience in database design, development, administration, and optimization. He can be found on the internet at, on e-mail at and is @guyharrison on twitter.

Related content from GigaOM Pro (sub req’d):

Comments have been disabled for this post