Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I'm curious about the necessary hardware and software requirements to support a strong MMORPG. For example, what kind of requirement (both hardware and software) would I need if I were to build a system that can incorporate million requests at the same time and avoid lags? How can I keep the game from glitching by processing the requests efficiently?

I understand it depends on proper programming and database structure. Assuming there is 1 table that will have 2 rows updated for every request and there are a million requests, what kind of system and database would I need to do that flawlessly without lags? What amount of time would it take to process all those requests?

Just wondering what I should expect if I'm going to develop a MMORPG.

I would really like to get your feedback/response on this.

share|improve this question
    
Most MMORPG's segregate their population into various "servers" (whether behind the scenes this is one or many is irrelevant). Decide a size that will give users an "everyone in the world" feel, then deploy multiples of that. No one is going to be upset when they have 50,000 other people to play with that you split everything up into 20 servers. –  ErikE Feb 19 '12 at 9:05

2 Answers 2

It really isn't a database platform problem. All the major databases and operating systems will do fine provided sufficient hardware with sufficient bandwidth to memory, disk, and network are provided.

All databases are built for this kind of scenario -- that is, where you need to update lots of rows from different clients all the time. This is what indexes and primary keys are used for, and the database is optimized for updating in this manner. (i.e., UPDATE your_table SET your_column=your_value where your_key=12)

The hardware requirements are going to be your biggest issue, and I suspect you will need to think about quite a lot here, including:

  • Failover (what happens when your main server fails?)
  • Clustering (You may simply need to have more than one database server to handle your load)
  • Processors (2? 4? 8? 16? Multi-core? Does the db provide multi-core support that is well optimized?)
  • Memory (The faster the better, but your chipset must be able to handle the bandwidth as well)
  • Disk (Faster I/O the better. eSATA/SATA or Fiber, etc.)
  • Network (You'll need lots of bandwidth to handle this kind of traffic)
  • Virtualization (Does it make sense to build this as real hardware? Why not as virtual servers in the cloud? Amazon / Rackspace / etc.?)

Thankfully a good majority of the scaling issues are handled either at the hardware or db level. That is, you can start your database now on a slow server and as traffic increases you can adjust accordingly with minimal changes to your code or your db structure. What will change is your hardware and your db configuration. Most database servers will support failover/clustering with little to no change to your existing code or structures. (But be sure to research possible costs and the efficiency thereof first)

share|improve this answer
2  
All data has to be written to disk eventually. If it isn't written to disk, and the power goes out, you've just lost everything. Disk always matters as disk is (almost) always the slowest component. –  mrdenny Aug 2 '11 at 7:42
1  
@mrdenny - true, but with Oracle at least, the physical writing to disk will be done by a background process, so will only cause lag if bandwidth is completely saturated for a period of time. A lot depends whether those 2 million writes per second are hitting the same blocks again and again or not. –  Jack Douglas Aug 2 '11 at 10:23
2  
Same situation with SQL Server, dirty pages are written to disk on checkpoint. But, theres still a transaction log record for SQL, or redo log for Oracle, that has to be written to disk on every commit. –  Mark Storey-Smith Aug 2 '11 at 14:01
1  
@Jack Douglas. don't mix log and data writes. All RDBMS use Write Ahead Logging for ACID. The data page may or not go to disk then, then the data change is certainly logged –  gbn Aug 2 '11 at 14:28
1  
@Jack Douglas: the recommendation for SQL Server is the fastest drives (and dedicated) for log files because of WAL. –  gbn Aug 2 '11 at 15:53

One million requests per second? With two row updates per request? I think the problem isn't the database, but the development!

My advice, forget about the cost for the database hardware and focus on the cost of development.

To understand where I'm coming from, consider this: Why would you need to do two updates per request? If you're developing an MMORPG, you're going to have 99% reading and maybe 1% updating.

For example, when a player moves from A to B, you will want to report that to the server, and send that to all other clients within a given range. Ultimately, yes, you will want to save that in your database, but I would only update the database every 5-30 seconds with the users location. If the server software crashes, the users will log back in having only lost 30 seconds of activity. That's pretty good.

So, if you have one user performing an update every 30 seconds, then you don't have that many updates. If you're going to try to host, say, 100,000 live connections, your biggest concern is not the database, but the hardware to support 100,000 connections, the RAM to run the server software, the hard drive space to store all the data, etc...

I would say, forget about the hardware cost and focus on the development cost. It will cost you far more to develop the MMORPG than it will to get a database that can handle an MMORPG.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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