Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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