How did you get into RDBMS?

Which database (RDBMS vs NoSQL vs BOTH) should be used for a real-time multiplayer game?


I'm working on a real-time multiplayer game that requires a database (for features like player profiles, friends, unlocks, messages, etc.). This is a standard PC game (not browser based) and uses a client-server architecture. I'm new to databases and have been doing some research in the past few days when I came across the heated debate: RDBMS vs NoSQL. I am currently leaning towards NoSQL, but after reading the uses for both (RDBMS and NoSQL), I am tempted to use both. I know this may seem strange, but let me explain my situation:

My team has a shared web hosting package that offers unlimited mySQL storage and unlimited bandwidth. The only restriction is that only 25 connections can be open at the same time (common hosting rule). I intend to use this for my website (a typical use no doubt) to post news updates, support community features (like commenting, uploading merchandise, etc.), and the like. All is well and good - but! This is where things get interesting ... I want to display the same information posted in the game on my website. This means using mySQL for both my website and my game. In addition to messaging and the like, I plan on using it in-game for things like chat and a server list. I am mainly concerned about this 25 link rule.

Which leads me to ask question 1: does this work and is there a better alternative?

Also, I've read about how well NoSQL works and is suitable for real-time gaming (I could be wrong, I went through a huge RDBMS vs NoSQL flame war to get here and I probably got burned). Basically, I want to use MongoDB for all of my game object data.

Again, it helps if I provide context: I found a host (MongoLab) that has a free 240MB MongoDB package that I want to use until an upgrade is needed. Given 240MB, I've calculated that I'll be able to store around 60,000 players (if each player is around 4KK and we ignore other things that might be stored). The storage space and having to pay more in the future (if our game is successful) is not a problem. The only reason I currently intend to use MongoDB for all of my game object data is because of how often that game object data is accessed (e.g. when a player is killed, picks up an object, fires a weapon, etc.) is also pleasing the simple schema-free documents (which facilitate the mapping of game object data). I should note that at once

I intend to use the same MongoDB on my website to display player profile information (I'm not interested in complete consistency, some delays in in-game updates are fine). Which leads me to my second question, Question 2: is this a good idea or is there something better that I should be doing?

The game will have a similar starting experience:

  1. Client logins (MongoDB)
  2. The client is on the home page of the game with chat rooms (MySQL).
  3. Client goes to server list (MySQL)
  4. The client connects to a server and plays in it

  5. Server communicates updates for all players (MongoDB)

This is exactly how I imagined it. Does this look good to you or do you have any suggestions on how this plan can be improved?






Reply:


My suggestion is that your game communicate with a web service that you have created and that does itself to query the database. At this point it is very easy to test different types of databases by "switching" web service implementations (your web service interface is always the same so that your game does not break) and deciding which is right for you .

It's also much safer not to expose your database directly to the internet.




Only 25 connections can be open at the same time (shared hosting rule).

That's more than enough for your game. The problem is that if your website uses multiple links you could leak. You need to configure your web server so that only a small number of them are used. The rest remains on your game server. Your game server doesn't really need more than one connection, but it could benefit from a handful.

Also, I've read about how well NoSQL works and how well it is for real-time gaming (I could be wrong, I went through a huge war between RDBMS and NoSQL to get here and I was probably burned). Basically, I want to use MongoDB for all of my game object data.

This is a wrong argument because neither Systems is fast enough to be used as main memory for fast real-time play. It is important to keep and edit the values ​​in memory. So you're only accessing the database when you absolutely have to, which may just be to save the entire character from time to time (say, once a minute), and at that point the speed differences become negligible.

The funny thing is, if you set MongoDB at full speed, you can get it almost to the point where it's fast enough to do synchronous writes in a relatively fast game, but that would cost the price of data integrity because the writes are buffered. This means that in the event of a crash, you will lose this data. So there is little point in actually doing the write, and it is still slower than if you just did the editing in memory and saved it later, so you get the worst of both worlds.

The only reason I currently intend to use MongoDB for all of my game item data is how often that game item data is accessed (e.g. when a player is killed, picks up an item, fires a weapon, etc.).

Wonder why you need to write to the database when a player fires a gun. Why can't this just be done in the game server's memory? If your game crashes and later restarts and the player realizes they have three more bullets than expected, is that a critical business problem?

I also like the simple schema-free documents (which make it easier to map game object data).

This is a much better reason to take a NOSQL approach than the performance issue.

I intend to use the same MongoDB on my website to display player profile information (I'm not interested in complete consistency, some delays in in-game updates are fine).

That is fine and makes sense. Later, you may want to use a separate instance so that reading and writing on the web doesn't conflict with reading and writing in the game. However, this problem is a trivial solution compared to the problem of getting so popular that it is a problem.

Personally, I would just pick one of the two databases that would be one less work for me to base on and standardize that - but there's no reason you can't stick with two if you want to.




All real-time data must be stored in the application memory, anything else would be nonsensical.

It's pretty easy to keep users' login credentials, statistics, etc. So I'll be brave and say you can use pretty much anything you want. Even though you want to be careful with the website, things like user lists can significantly affect database performance if you don't use a proper caching system.

And like Bummzack said, you should keep everything on the same network. Additionally, you should be wary of free content, 240MB of free database space sounds fine, but since the machine is likely to be split among a large number of free users, the service can be quite slow.





Do you trust your 60,000 users per database? If not, you should ignore the idea of ​​"database access from the client" unless you have excellent knowledge of database software security and are confident that you can handle any problems that may arise.


We use cookies and other tracking technologies to improve your browsing experience on our website, to show you personalized content and targeted ads, to analyze our website traffic, and to understand where our visitors are coming from.

By continuing, you consent to our use of cookies and other tracking technologies and affirm you're at least 16 years old or have consent from a parent or guardian.

You can read details in our Cookie policy and Privacy policy.