I was wondering what sort of benefits a nosql option might have either in lieu of, or in conjunction with a rdbms for a typical MMORPG. In particular, I'm curious as to how data integrity is preserved under nosql.
I'll give a few examples where I'm kind of confused as to how server logic would operate:
Scenario 1: Let's say player A and B attack player C at the same time. A player_stats.kill_count is updated for whichever player kills player C. Normally, one might handle this AttackPlayerRequest in the following way:
Begin Transaction { attacker.health = newAttackerHealth
defender.health = newDefenderHealth
if defender.Health == 0 { attacker.stats.kills += 1 } }
Scenario 2: Player A sells an item to an NPC vendor, and quickly attempts to drop the same item from their inventory to the ground. (Even if you're UI disallows this, they can certainly just put the events on the wire).
This list obviously goes on and effects just about every player-player player-world interaction. One last piece of information is that the server is threaded as we don't want any particularly lengthy request to block other players from being able to do simple things in the game.
I guess my big question here is, am I misunderstanding something about nosql wherein this a trivial problem? If not, is this beyond the domain of what nosql options are meant to solve? Under a typical MMO, where might one inject nosql options to increase server performance?
That said, most MMOs do run on SQL (relational) databases.
“MongoDB has been central to us scaling from zero to over 4m users in just 18 months.” “I think games benefit from MongoDB's flexibility because changes are quite frequent and relying on rigid schemas just isn't practical. MongoDB is a big time saver in that respect, especially for gaming.
NoSQL databases can flexibly support both read-heavy and write-heavy systems. With data spread out across multiple shards/servers, hashing and consistent hashing are very important techniques for determining which shard(s) to route application queries to.
Not Quite The Right ChoiceMost databases in NoSQL do not perform ACID transactions. Modern applications requiring these properties in their final transactions cannot find a good use of NoSQL. It does not use structured query language and are not preferred for structured data.
This all depends on how your game operates.
NoSQL
Farmville on facebook uses NoSQL. Farmville acts like 1 enormous server that everyone is on. Let's say Farmville uses 3 computers in its database cluster. Computer 1 in San Diego. Computer 2 in New York. Computer 3 in Moscow. I login to Facebook from San Diego so I connect to the database here. I level up and log out. Eventually Computer 1 Will tell computer 2 and 3 about how I leveled but it could be up to an hour before someone in Russia would see those changes to my account.
NoSQL scaling is as simple as adding another computer to the cluster and telling the website in that region to use that computer.
SQL
There are several methods of making SQL Work but I will explain a way to make it similar to NoSQL
Each Data-center will have 10 game servers, each with its own SQL Database + 1 Sub Master Database. The Sub Master Database shared the information between all 10 servers so if you login to server 1 and make character John Doe, then logout, Server 10 will have your character if you login to that server next.
Sub Master then shares its information with the Master Server at your HQ. The Master Server will then share John Doe to every other sub master at all the other data-centers, and those sub masters will update their game servers. This configuration would allow for you to login to server Weed in San Francisco, play your character, logout, login on server Vodka in Moscow, and still see your character.
Games like World of Warcraft use SQL but only certain parts of the database are shared. This allows for reduced Database size on each computer and also reducing hardware requirements.
In a real life situation each Sub Master would have a backup Sub Master, and your Master server would have a few backup servers in the event that one server goes down your entire network would not lock up.
I think MMO servers would do a lot of the stuff you've listed in memory. I don't think they flush all of those out into the database. I think more hard-set events like receiving new gear or changing your gear layout would be saved.
It's a lot of data, but not nearly as much as every single combat interaction.
MMORPGs that are worried about latency typically run on a single server, and store everything except object model information in RAM. Anything with battle environments are worried about latency.
Anything that uses HDD, be it an RDBMS or NoSQL, is a bad idea in battle environments. Updating and sharing object customization, position, movement vector, orientation vector, health, power, etc... data between 10,000 users on a single server via any mechanism that uses HHD is just silly if you are worried about latency. Even if you have 2 people fighting in a simple arena, latency is still an issue and you should run on a single server and keep everything in memory. Everything that will be rendered should be on your PC or in the memory of your PC as well.
MMORPGs that are not worried about latency can run on multiple servers and any database you wish (NoSQL, MySQL, etc...)
If you're making a game like farmville or neopets, then yes, NoSQL or MySQL become valid options.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With