8

I'm currently making an MMORPG game, which could have a few thousand players online at the same time (probably not; just wishful thinking). First we wanted to use MySQL, but I have heard it isn't fast enough for this scale.

Which DBMS is fast enough? How much like SQL Server is it (as I have learned SQL Server in school)?

Improve this question
2
  • Just as a point of reference, World Of Warcraft is Oracle-based.
    – Philᵀᴹ
    Apr 27, 2012 at 16:10
  • Whatever DBMS you choose, don't forget to take licencing into account. Maybe your free version is fine for small loads, but if and when you have to scale up or out you may experience a severe case of sticker shock.
    – datagod
    Apr 27, 2012 at 17:38

9 Answers 9

Reset to default
24

This is a really tough question to answer. You can take the fastest database platform in the world, design a horrible schema, write a crappy application around it, and then be tempted to blame the database platform. At the same time, you could take the free SQL Server Express and, with the right design, application logic, and an approach at sensible scalability (e.g. scaling out reads by data caching, etc), you could write an application that handles 1000s of users no problem.

Do I believe SQL Server can handle 1000s of users? Absolutely. Do I believe Oracle and DB2 can do so as well? Certainly. MySQL? Not sure, not enough experience there. Access? Probably not a wise choice at all. If you are familiar with SQL Server, then I suggest that is the route you consider, just keep in mind that your choice of RDBMS will not in and of itself dictate success or failure.

Improve this answer
4
  • Well, i just needed a guideline. It's not that a small indie game will reach 1000s of simultaneous users right away. Thanks!
    – Simon Verbeke
    Jul 7, 2011 at 18:45
  • 3
    While you may not be planning to hit 1000s of users at once right away, if you don't plan correctly from the beginning you'll end up in a situation where you have to take a large outage or at least have some major slow down for a while, while you work on fixing the problems.
    – mrdenny
    Jul 7, 2011 at 23:45
  • Right, and here is a timely article explaining how facebook is now feeling the burn for their initial design decisions based on "we'll never get huge" arguments: gigaom.com/cloud/… ... just noticed this article was also referenced in Rolando's answer
    – Aaron Bertrand
    Jul 8, 2011 at 15:11
  • @Aaron : Good stuff. +1 for you answer because software infrastructures around MMORPG should be database agnostgic and still behave itself !!!
    – RolandoMySQLDBA
    Jul 8, 2011 at 22:16
12

Let me put it this way, remember GameSpy Arcade from the early/mid 2000s? It ran thousands of games, and was all running on SQL Server and supported tens of thousands of users at once (yes we had several SQL Servers in there doing various things). It's all about the design of the database and how you use the system. Do so correctly and your project will succeed, do so incorrectly and your project will fail, badly.

Improve this answer
2
  • Nice to know that info about GameSpy, especially since I had used it. Never knew about the SQL part all that time.
    – StanleyJohns
    Jul 8, 2011 at 9:08
  • 1
    Don't forget, back then the newest version was SQL 2000 and we have 1+ Billion row tables. We had a pretty good rep for keeping systems online under high load.
    – mrdenny
    Jul 8, 2011 at 21:52
11

The right answer depends a lot on the platform you are programming for.

It just so happens that someone asked this question for a specific platform in StackOverflow about 1.5 years ago.

Whether it is MySQL, SQL Server, Oracle, PostgreSQL or some other RDBMS, you have to be very creative with the database infrastructure. If you have an open checkbook for hardware and an industrial-strength DBMS, Oracle is for you (if fact, Oracle RAC would be more desirable). If you are developing using IIS and a Microsoft environment, then it is SQL Server all the way. If you have budgetary concerns and want an Oracle look-and-feel, PostgreSQL to the rescue. If you have budgetary concerns, a vivid imagination, and want to micromanage the Storage Engine to your liking to accommodate ACID-compliance, high speed reads, and a variety of replication architectures, I would prejudicially say MySQL.

The DBMS should be the least of your worries with MMORPG. Programming issues always present bigger fish to fry. So, make your decision prudently and wisely, because whatever DBMS your choose, you have to live with it (the same way FaceBook has to live with MySQL).

Improve this answer
2
  • 2
    That's the third reference I've seen to that Facebook article today. It's a pretty good article.
    – mrdenny
    Jul 8, 2011 at 8:38
  • 2
    +1. MySQL is usually overlooked, but it is a really powerful RDBMS.
    – StanleyJohns
    Jul 8, 2011 at 9:13
7

This isn't the right question. The performance of your game will depend on the complete architecture and technology stack you choose and on how it is implemented. The DBMS is just one component of the stack. I would hazard a guess that the DBMS is unlikely to be a limiting factor on performance unless you architect things very poorly. Your domain layer, cacheing and how you distribute and scale out the site seem likely to be much more important concerns.

Improve this answer
5

Any RDBMS will fall down with scale depending how it's configured, scaled and how the application utilizes it.

Me thinks, you've got two questions in one. The first, "what DBMS are capable of persisting game data in an efficient way." (subjective, imho) The second, "how do I scale that DBMS to perform with 1000s of users?"

Many online services have found the combination of MySQL and Memcached to provide excellent performance and scale. However, there comes a point where that solution falls down too. However, it might be exactly what you need.

More and more online services are sandwiching in a NoSQL solution into their architecture. I have some experience with CouchBase and find it useful.

Improve this answer
4

Code, design and your disks (for writes) determine performance generally. Not the platform.

Improve this answer
2

You could take a look at CUBRID. It's an open source RDBMS that's very "hot" in South Korea right now. It's suppose to work best/ really fast for web applications with high number of users (they say 50k or something like that).

Improve this answer
1
  • CUBRID, in fact, not just a Relational DBMS but also provides Object functionality. The object part is exactly what Game Developers need. In CUBRID you can easily create User Defined Types. Eg. a table can have a column, which has a data type as another table like: CREATE TABLE a ( id INTEGER AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255) ); CREATE TABLE b ( id INTEGER AUTO_INCREMENT PRIMARY KEY, custom_column a ); This type of functionality is highly valuable for game developers. Popular online games in South Korea are based on CUBRID.
    – esengineer
    May 22, 2012 at 1:30
2

I think any of the major databases can handle the load if designed well. Sadly I would estimate that less than 1% of all databases are designed well. (I have personally dealt with data from literally thousands of different databases performing a wide variety of functions, so I think I have a good idea of the lack of quality that is out there inteh real world.)

I would strongly suggest that you get some books on performance tuning for the database you choose and read them thorughly before begining to design. There are many things that will help your database perform better that should be designed in from the start. Just knowing how to write performant queries and design indexes is critical to getting a good design. This type of study and designed-in performance is not premature optimization. There is no reason at all to use known performance killing techniques in the design. Databases need to be designed for performance from the start.

Improve this answer
0

We have mobile games with 1000s of players and we saw a huge drop in load by going to persistent IIS/.NET mysql connection pools. mysql 5.1

Think about keeping "write only" data somewhere else to reduce load on whatever db you choose Cassandra or syslog even. Think about keeping quickly changing, highly transient but reconstructable data in a nosql db like memcache, riak, etc.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.