4

I'm gathering information for upcoming massive online game. I has my experience with MEGA MASSIVE farm-like games (millions of dau), and SQL databases was great solution. I also worked with massive online game where NoSQL db was used, and this particular db (Mongo) was not a best fit - bad when lot of connections and lot of concurrent writes going on.

I'm looking for facts, benchmarks, presentation about modern massive online games and technical details about their backend infrastructure, databases in particular.

For example I'm interested in:

  • Can it manage thousands of connection? May be some external tool can help (like pgbouncer for postgres).
  • Can it manage tens of thousands of concurrent read-writes?
  • What about disk space fragmentation? Can it be optimized without stopping database?
  • What about some smart replication? Can it tell that some data is missing from replica, when master fails? Can i safely propagate slave to master and know exactly what data is missing and act appropriately?
  • Can it fail gracefully? (like postgres for ex.)
  • Good reviews from using in production
RawCode
  • 1,073
  • 8
  • 13

2 Answers2

0

Start with the premise that hard crashes are exceedingly rare, and when they occur it won't be a tragedy of some information is lost.

Use of the database shouldn't be strongly coupled to the routine management of the game. Routine events ought to be managed through more ephemeral storage. Some secondary process should organize ephemeral events for eventual storage in a database.

At the extreme, you could imagine there being just one database read and one database write per character per session.

ddyer
  • 1,792
  • 19
  • 26
  • Database should manage data as it see fits. It's good from resilience point of view. What if this middle-manager dies with server it is on? All hard-earned, or even brought, game points are lost! I want to sleep at nights, not restore lost data. I updated the question to include gracefull failovers. For ex: one of my customers turned off fsync on old version of postres (>9 is fine) for perfomance reasons, and had 48h shifts every now and then (several times a month) to restore data after server crash. – RawCode Jan 07 '13 at 08:57
0

Have you considered NoSQL ?

NoSQL database systems are often highly optimized for retrieval and appending operations and often offer little functionality beyond record storage (e.g. key–value stores). The reduced run-time flexibility compared to full SQL systems is compensated by marked gains in scalability and performance for certain data models.

In short, NoSQL database management systems are useful when working with a huge quantity of data when the data's nature does not require a relational model. The data can be structured, but NoSQL is used when what really matters is the ability to store and retrieve great quantities of data, not the relationships between the elements. Usage examples might be to store millions of key–value pairs in one or a few associative arrays or to store millions of data records. This organization is particularly useful for statistical or real-time analyses of growing lists of elements (such as Twitter posts or the Internet server logs from a large group of users).

There are higher-level NoSQL solutions, for example CrouchDB, which has built-in replication support.

Mihai Rotaru
  • 1,953
  • 3
  • 26
  • 28
  • NoSQL are not good for updates. They are optimised for reads, at the expense of asynchronous writes – Bohemian Jan 06 '13 at 21:42
  • I have considered NoSQL. As you can see from question, i have experience with mongodb, and it did't fit well in online game scenario. Thou key/value store is fine for a game, perfomance and stability was not. As for CouchDB it seems like more of a web solution, with the same quirks as mongo, but i'll look into it. – RawCode Jan 07 '13 at 08:33