What kind of databases are usually used in an MMORPG? [closed]

Question

Do people write their own DB for some reason?

Answer 1

We did, hopefully Ben Z will give a better explanation of the reasons than I can since he was actually the original author of our database. The short version is that relational DBs are not very useful for games because they cannot efficiently store heavily structured hierarchical data, which makes up the vast majority of data an MMO needs for normal operation. We choose to build a custom object database and part of a distributed transaction processing system, which is now in production and powering our two live games.

As for if you should do the same? Probably not, at least not at first. I would still advocate avoiding SQL, but there are now many more options in the "NoSQL" world that didn't exist a few years ago.

That said, most MMOs do run on SQL (relational) databases. I know Eve runs on a SQL Server installation sitting on top of a few multi-TB RAMSANs (I will probably never in my life have as much money as those things cost).

EDIT: Hopefully he won't mind me posting this here, but this is a blog entry with some links and comments about the presentation we gave at GDC'08 about our database.

Answer 2

Okay this answer is more of an observation.

Full disclosure I haven't worked on MMORPG. I have worked at what was one of the top 10 most visited sites back in 2009, and I have worked at game engine company that thought they were making MMORPG tech (I don't know if shipped).

If you look at companies that have achieved massive scale (Google, Facebook, Twitter, etc., I know they are not game companies, but they are worth looking at in this space) there are two things that I think are important.

1. They started by grabbing whatever was cheap and easy to get themselves going
2. They ultimately had to roll a lot of their tech on their own. (And sometimes hardware)

A big mistake is to grab some expensive turnkey thing and expect it magically scale for you. It doesn't work that way. The key to scaling up is dealing with each new challenge appropriately. You need flexible easy to use solutions that you can move in and out easily.

So my advice to you would be if your starting out, just get what seems least headache to deal with.

Answer 3

Basically, there's a whole range of approaches, and I think they're chosen based more on the experiences of their developers as much as the properties of the database. At one end, many MMOs are using standard relational databases - eg. Dark Ages of Camelot used/uses (are they still going?) MySQL, FreeRealms use a modified Postgresql, etc.

Moving along the scale, you have Guild Wars: they use SQL Server, but they stick their data in there as a single BLOB. This means they get the benefits of their usual binary formats with some of the benefits that a database provides. Needless to say, you can probably see some disadvantages of this approach too, but for a company used to working with flat files, it's probably still a step up.

Then there are probably some places using the various formalised NoSQL approaches, although it's still early days yet. Farmville uses membase, which they made for the purpose, based on memcached apparently. This shares many features with the likes of MongoDB, CouchDB, etc. Again with these approaches you're typically rolling your own storage formats but get the benefits of distribution, caching, redundancy, etc.

Some are rolling their own NoSQL entirely: Cryptic said they did something similar but also said they weren't using it in production. (EDIT: but see comments below.)

And then you come to people who are using flat text or binary files - as I understand it the older games like Ultima Online, Everquest, etc all went down this route, and for a company with game development experience but little database experience this works well too.

Note also that you almost never get around writing your own database in some loose sense of the term - in games you'll always have bespoke data that you need to manage either in-memory or on-disk in ways that don't lend themselves to generic software. You can't do SQL queries every time you want some data so you will need to be mirroring a lot of your information in the code no matter what back end you use.

Answer 4

On Pirates of the Burning Sea, we stared off with MySQL (though honestly I would've preferred Postgres) and when it started falling down under load, we switched to Microsoft SQL Server. Honestly, though, I probably won't go that route again in the future. Most of the PotBS data is pre-serialized before it's persisted anyway, so a large portion of what's in the DB is nothing more than an overgrown key/value store. On top of that, to get better performance out of our persistence layer, and better control of how data was cached in memory, we ended up writing a caching server that sat in front of the database.

So Kylotan's very right, you're not going to get around rolling your own on some level. SQL relational database servers aren't designed for the way games use data. Instead of assuming relational DB servers were the end-all of databases, we really should have thought more about what benefits we were looking for before choosing a tool.

Next time around, I'd look more into things like BerkleyDB or some of the other NoSQL-style DBs.

Answer 5

One other thing to note is that if you have a (relatively) static data set, don't store it in a database! There's no really good reason to store your spell definitions, item definitions, maps, etc. in a database. You're rarely querying them except by name. I see a lot of people jump into game development storing these things right alongside persisted player data, and it's a totally different class of things.

You need a data store, like a filesystem, for these. Outside of development, you don't need ACID, you don't need CRUD, you don't need a database for that kind of data. Inside of development, you need a database, but you also need a VCS anyway, and your choice of VCS will make that choice of database for you.

(If you're working on a game where players can create custom spells or items or quests, well, then that data is the same sort as player data, and you do need a database again.)

Answer 6

I've used MongoDB (NoSQL), it's a very fast document store that can be accessed over TCP. Give it a try! It's awesome!

Writing your own DB is a daunting task. I suggest you first explore what's already out there and if you can't find any thing that matches your specific set of criteria, build your own. Oh, and don't forget to open source it. :)

Answer 7

MMORPGs are intensive apps and are a huge undertaking. If you are starting off with game development I strongly recommend you do something smaller.

That said you will need two squeeze top performance out of your setup. You are obviously going to need a server farm/hive. Because network communication is relatively expensive (and most MMORPGs are realtime) you might want to replicate your central database to each of your game servers (the equivalent of realtime low-latency replication in your database of choice).

If each of your servers are serving a specific segment of the game world (like WoW works); something like Distributed Partitioned Views. DPVs allow you to segment rows of your database across different servers; according to the the constraints on the columns at each server. Both MSSQL and Oracle are smart enough to only talk to the server that contains the data that falls within your WHERE or ON clause. I am not sure if any of the open source offerings have DPVs.

The net result of this all is that it doesn't matter what DB you use, just use one with a good name: MSSQL, Oracle, MySQL, PostgreSQL. Write your database in ANSI SQL and see which system works the best - that's the only way to find out.

The NoSQL route might also be a good idea because it's designed for high concurrency. Pranny's suggestion might do the trick.

Answer 8

I guess it depends pretty heavily on what kind of data you need stored, and under which form.

I think most people out there use "standard" SQL databases for "dynamic" data like player informations, be it SQL Server, MySQL, PostgreSQL.

However, "internal" data (state of the world, content, ....) can be stored under any form, and my guess would be that most company write at least partially custom databases systems for that part, suited for their specific needs.

Answer 9

Well, it actually depends on your application - that's the bottomline. I work, where we develop social RPGs and we use Google App Engine as a backend

Answer 10

This question is rather old but my Idea of how to handle it is as valid as it was asked as it is today.

If you're using a relational database you need to reduce the load on it so this idea should help.

Store all public info on a local DB on each client system as well as in the servers DB.

Store all tables with items on the client database. Instead of the client looking to the server when you mouse over that weapon for stats, the client just checks the local database for stats. The server has its own database for pulling stats when calculating and just forwards damage and health remaining to the clients.

Worst case with this idea is that everyone can see the stats to all weapons if they manage to get into the clients database. it doesn't matter though cause even if they change the values, the database values on the server are what does the calculating in the game.