Download Choosing the Right Database for Your Social Game

Choosing the Right Database
for Your Social Game
CHOOSING THE RIGHT DATABASE FOR YOUR SOCIAL GAME
Summary
When building and launching a social game, being ready for growth is critical to your
success. Many games have accelerated from zero to millions of users literally overnight —
OMGPOP’s Draw Something game recently reached 50 million downloads within 50 days of
the launch. Figuring out how to support that kind of growth, while sustaining a snappy and
compelling gaming experience, presents an enormous challenge at every layer of the game’s
technology stack. To power all this virtual online activity, a solid backend system is needed as
the demands on the social game applications fluctuate. Choosing the right database for your
social game requires careful thinking about important issues such as elasticity, consistent
predictable latency and throughput, and data model flexibility.
Is the database for your game ready?
1
© 2012 COUCHBASE ALL RIGHTS RESERVED. WWW.COUCHBASE.COM
CHOOSING THE RIGHT DATABASE FOR YOUR SOCIAL GAME
Social gaming is a fiercely competitive “hits” business. Most social games have fewer than
a 100,000 daily active users (DAUs). Every game developer’s dream is to have their game
go viral and shoot to the top of the download and DAU charts. Staying at the top can be as
hard as getting there. Once there, a game needs to continue to evolve quickly to stay fresh
and retain users. In this environment, selecting the right database is more critical than you
might think. If you don’t, all the hard work done to create a compelling game could be wasted
because the game couldn’t scale and players desert your game it in frustration.
The capabilities of NoSQL databases fit social games particularly well. Many have already
incorporated NoSQL databases and the vast majority will likely to do so by the end of 2013.
There are many NoSQL technology choices however and it’s not always obvious how to select
the right one. Here are a few of the most critical attributes of social games along with some
thoughts about how they might influence your selection of a NoSQL database.
Large Number of Users/Rapid Growth (Scaling)
Social games are designed to be viral and exploit a person’s social graph. When they go viral
you not only need to deal with a large number of users, you also need to deal with a constant
stream of new users – often more than 1 million new users per day. In social games, each
individual game is easy to scale because the number of friends in a player’s social graph
usually limits them. But, the sheer number of users actively playing games makes it difficult
to scale the total system.
Several recent examples illustrate the
importance of scalability. A negative example
was EA’s The Simpson’s: Tapped Out. Launched
on March 2 2012, the game starts when Homer
accidentally causes a meltdown that wipes out
Springfield. Unfortunately, the game melted
down too. An incredibly successful launch, by
most measures, the game hit #2 on the App
Store immediately after it was made available.
But just four days later the app was pulled from
the App Store. EA didn’t published details,
but a review of player complaints implicates
the game’s infrastructure (in particular, the database infrastructure), which was apparently
overwhelmed by the growth. And, obviously, it was non-trivial to fix the situation.
2
© 2012 COUCHBASE ALL RIGHTS RESERVED. WWW.COUCHBASE.COM
CHOOSING THE RIGHT DATABASE FOR YOUR SOCIAL GAME
In vivid contrast, OMGPOP launched Draw Something just
a day after the article was published. Draw Something was
extremely successful from the start and just kept on
growing – it fact, it hit 50 million downloads in 50 days
without any scaling issues.
The selection of a database will have significant impact on
not only how a game scales but whether it scales. One of the
biggest mistakes many social game developers make is not
carefully considering database scaling as an integral part of
the database selection process.
First, look for a database that can actually scale to 50, 100
or more nodes. Most NoSQL databases have no problem
operating in a small 1-5 node cluster but operating on a 50 or
100 node cluster is far more complex and not every NoSQL
database is up to the task.
Second, look for a database that doesn’t require you to make any changes to your application
when scaling the database -- you shouldn’t have to do application-level sharding with a
NoSQL database.
Third, look for a database that provides effective auto-sharding. A database should use a
sharding approach that balances the load evenly across the database cluster. Having a cluster
with “hot spots” will cause big scaling problems that will sap the performance of your game
and increase your costs.
Finally, look for a database that provides on-line, on-demand cluster sizing. Adding or
removing capacity should be a single, simple operation when you’re growing from 1 to 25
to 50 nodes or more. There is no reason you should need to fight with complicated scaling
procedures. When a game does go viral it needs to be able to scale immediately. There isn’t
any time to hire new ops resources, deal with unforeseen scaling issues, or make changes to
your game to support scaling.
Game Responsiveness (Performance)
Responsiveness is something that can make or break a game. Social games need to be
responsive and perform game actions quickly. If a player is unable to complete an action
quickly - for example using an in-game item they have just purchased to perform a time
sensitive task or participate in a game quest - the player may get frustrated, leave the game
and never come back. Game players are demanding and there is a growing body of research
that confirms high dropout rates for even slightly unresponsive applications.
3
© 2012 COUCHBASE ALL RIGHTS RESERVED. WWW.COUCHBASE.COM
CHOOSING THE RIGHT DATABASE FOR YOUR SOCIAL GAME
Document and key-value NoSQL databases generally support very high performance. They
keep related data in a single document in memory and on disk making it faster to read and
write data than relational databases. But all NoSQL databases are not created equal. Look
for a NoSQL database that consistently provides sub millisecond latency for reads and writes,
at scale. “Consistently” should mean 99% of the time regardless of the mix of reads and
writes to the database.
Multiplayer online games have thousands of players playing the game concurrently. However,
managing concurrency in games has always been a complex task, generally due to coarse
locking mechanisms in the backend databases. Lock granularity is important to be able to
provide efficient concurrent actions that change game state. Look for a database with finer
granularity locks (for example at the document granularity) for higher degree of concurrency,
consistent and predictable throughput as you scale, regardless of the mix of reads and writes.
Free to Play (Cost)
Most social games are free to play. But they still cost money to run. For most games, only a
small percentage of users ever pay anything to play the game. As a result, it is important
that you have a scalable database tier that is low cost from a software and hardware
perspective, requires minimal operational support, and scales linearly in cost with the
number of DAUs. To minimize costs during the pre-viral days, it often makes sense to
leverage free community editions of open source database projects and run on cloud service
platforms like Amazon. But be careful that you spend enough time thinking through how
your software, hardware, and operational management costs will scale with the number of
DAUs if you go viral. There are big differences between databases and by the time you go
viral it will be too late to make changes.
Look for a database that can provide the highest throughput while simultaneously providing
the consistent, sub millisecond latencies you require for responsiveness. Some databases
might be able to provide sub millisecond latencies but only provide per node throughput of
5,000 ops/sec while others can provide the same latencies at 2-3x the ops/sec. The difference
in the associated costs of the software and hardware can be significant. Also, look for a
database that is easy to administer. Adding, removing, and failing over nodes should be
“push-button”, every node in the cluster should be identical, and monitoring and alerting
tools should be extensive and easy to use. At the end of the day it should be easy to manage a
rapidly scaling data tier with 1-2 people. More complex systems will require much more than
this and add to your costs.
4
© 2012 COUCHBASE ALL RIGHTS RESERVED. WWW.COUCHBASE.COM
CHOOSING THE RIGHT DATABASE FOR YOUR SOCIAL GAME
Global Play (Always On)
Like most applications these days, social games are played around the world 24x7x365.
When games are down due to maintenance, players are frustrated and the game developer
loses money. Ideally, you never want your game to be off-line for hardware upgrades,
software upgrades, failed servers, etc.
To ensure that your game is “always on”, look for a NoSQL database that:
• Allows you to do online upgrades to the latest revision of the software
• Allows you to easily remove a node from the cluster for maintenance
without affecting the availability of the cluster
• Can handle online operations such as backup and restore
• Provides database disaster recovery support through cross-datacenter
replication
Rapid Change (Flexible Data Model)
The social game market is fiercely competitive and players are fickle. Players have lots of
choice in the games they play and new games are coming to market at a furious pace. Social
gaming is still relatively new and everyone is still learning, so it is critical to be able to do fast
iterations on a new game to get the dynamics right. It is just as important to iterate quickly
after you go viral to keep the game fresh, maintain players, and grow the player base. Game
developers can’t tolerate long design cycles or long release cycles.
Key-value and document-oriented NoSQL databases provide a very flexible data model that
allows you to make changes quickly. JSON documents can be stored in either type of NoSQL
database and provide a schema-less data model that is extremely flexible and easy to change.
If you want to add new data types, just add the data to the appropriate documents. There
is no need to call a DBA, modify your schema, move your database from the old schema to
the new, or change your application. Any key-value or document database will give you this
capability and document databases give the added capability of indexing and querying at the
data layer.
If you are considering building a social game, think about the infrastructure requirements
to support growth. As discussed, the most important issues for managing data in social
games are scalability, consistent and predictable throughput and data format flexibility. All of
which, NoSQL document-oriented databases address.
Your choice of database technology is arguably the most important infrastructure component
decision you will make. Download Couchbase Server at www.couchbase.com. We think
you’ll quickly see why such a large number of social games have selected Couchbase to be
their database.
5
© 2012 COUCHBASE ALL RIGHTS RESERVED. WWW.COUCHBASE.COM
CHOOSING THE RIGHT DATABASE FOR YOUR SOCIAL GAME
About Couchbase
Couchbase is the NoSQL database leader, with production deployments at Zynga, EA,
Playdom, IGT/DoubleDown Interactive, Shuffle Master, Playtika/Caesars Interactive
Entertainment and hundreds of other household names worldwide. Couchbase Server is
the simple, fast, elastic NoSQL database that delivers a more scalable, high-performance,
always-on and cost-effective approach to data management than relational database
technology. It is particularly well suited for web applications deployed on virtualized or cloud
infrastructures. Couchbase, the privately held company behind the Couchbase open source
project, is funded by Accel Partners, Ignition Partners, Mayfield Fund and North Bridge
Venture Partners. www.couchbase.com
6
© 2012 COUCHBASE ALL RIGHTS RESERVED. WWW.COUCHBASE.COM