Ashley Martens Developer at DeNA
Evolving from MySQL to Cassandra
At the time we were using MySQL for our solution but we had come to it’s blob limits. We had several criteria when we were evaluating NoSQL solutions: write speed, ability to handle large data (blob), ability to scale and fault tolerance. We had evaluated Cassandra and MongoDB, but at the time MongoDB’s global write lock killed it’s performance.
Cassandra for game states
We use Cassandra as a large data store, mostly for things like game state. As a player progresses through a game they accumulate items, experience, etc. and Cassandra helps keep track of that. For games that do not want to run a server that tracks this data we have a service that acts as a per user and game key value store.
We use two versions of Cassandra, 0.6 and 0.7, because of the cluster downtime requirement to upgrade and the Ruby driver’s inability to talk to two clusters of different versions at once.
We are in two data centers with 15 to 20 nodes per data center. In each data center we are storing around 10 TB of data. We modeled our IP ranges for the rack inferring snitch and use the network topology strategy to distribute the data.
Words of wisdom
Be proactive in adding nodes to the cluster. Don’t be afraid to bounce every machine in your cluster. Invest in tools for managing your cluster. Pay attention to the logs. Make sure you understand the data model and it fits your use case. Try to stay near current stable.
When I needed help the community was there for me. Now there aren’t that many people that know the older versions so I spend a lot of time in the source code to solve problems.