NoSql option for MMORPGs

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?

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.

To my understanding, nosql technology is something you would use in a batch job context, and not in a real-time context. As a matter of fact, the open source H-base implementation sits on top of the hadoop distributed file system (hdfs), which is primarily used for read-only situations.

The idea is that you 'seek' a record by iterating over the whole data set you are keeping 'on disk' (on a distributed file system actually). For petascale datasets it is infeasible to keep things in memory, so you utilize massive amounts of disk reads to be able to 'seek' the data at all. The distributed nature makes sure (or facilitates) that this occurs in a timely fashion.

The principle is that you bring the processing to the distributed data, instead of pulling data from a very large database, sending it over the network and then process it on a local node. Pig (http://pig.apache.org/) and Hive (http://hive.apache.org/) are interfaces on top of hdfs, which allow for SQL-like queries, but in the background, they use mapreduce jobs. Interaction is slow, but this is not the point. The point is that the immense data set can be processed at all.

For gaming, this is obviously not the way to go. So you would expect that data to be fetched from the distributed file system, cached on a server, and used during a session, When the game has finished, all data would be committed back to the data set. (At least, that's how I imagine it would go).

Hdfs data sets are mostly processed at a certain point in time, after which the results are being published in one batch. For example, in a social network site, you would compile all connection data on a daily basis, search for all new connections between people, and when the operation has finished for all people in the data set, the results would be published in the typical 'X is now conected to Y' messages. This does not happen in real-time.