Thanks for the article. I have a question. What kind of latency do you experience using MongoHQ? And maybe you could discuss this part of the system a little more?
The latency gets up to about 60ms+ but it's mitigated by caching a lot of the data temporarily. MongoHQ are using Amazon so if you're also using AWS it's going to be negligible.
I use MongoDB for a few components - user-created levels and leaderboards are the biggest parts. The big advantage is I can let developers attach custom data to scores/levels without having to even think about it - it slides right in just like any other property, and it's just effortless. The other big advantage is price - they're a lot cheaper than getting another server.
The leaderboards is the biggest one running at a total of almost 10 gigabytes because of the indexing.
I use MongoHQ because there's a learning curve with MongoDB that I never have time to explore properly, originally I ran it myself and even got it sharded and replicated, but when it falls over (and it did) you really need to know a lot more than I do about it. Those guys are awesome and I plan on building more on their service.
I use the Samus C# library for it, I noticed recently there's an official one now but it didn't exist when I started using it. One of these days I will upgrade to that.
Here's the leaderboard database stats. Mostly it's just lots of reads, and only if whichever server doesn't have the requested data in-memory already.
btree accesses 0.47 /sec
btree miss ratio 0.2%
global lock ratio 0.1%
indexes 8
objects 24,222,154
op deletes 0.00 /sec
op get mores 0.73 /sec
op inserts 0.57 /sec
op queries 4.02 /sec
op updates 0.02 /sec
all ops 0.02 /sec
size of data 3.3 GB
size of index 6 GB
size of storage 3.7 GB
uptime 4 days
connections 128
