Are there any pratical examples of database implementation for an MMORPG in CouchDB? Even a detailed thesis? I've looked but found very little on practical examples and not even find any good UML examples and plus I see a little bit of an issue with the lack of schema and design by UML. Maybe It's more of a paradigm change but I'm ideally looking for something that has things like:

Same way you design any other database, make sure you have got an index for all ways you wish to access data. The slightly more tricky part is figuring what to put in the database and what to keep in application memory. Apart from that there is only the same thing that can be said for almost all MMO questions: If you need to ask, you should not be developing an MMO.
–
eBusinessJan 13 '12 at 23:23

1

Yeah - game design comes first, then data design second. Once that's done you know what you need to store and whether you use CouchDB or MySQL or flat files becomes a largely irrelevant detail.
–
KylotanJan 14 '12 at 17:59

2

I'll just add that people are as funny about their MMO pixel items as they are about real cash, so whatever you do if it isn't ACID you're just playing with fire and you will get burned.
–
Patrick HughesJan 15 '12 at 0:00

2 Answers
2

It is certainly possible but I haven't seen any direct examples. A NoSQL database may be better for MMOs when we consider their scalability across multiple servers. SQL engines can do the same thing but generally require a whole lot more planning and money to do so.

Having messed around with MaNGOS' source (World of Warcraft private server) I can say that the majority of data used is loaded into memory when it is needed and there isn't a high complexity of relational data. Data written to the database is really just a backup for what is in memory. When data is no longer needed in memory it is dropped.

Database type is going to be dependent on how you structure your game engine. If you only load portions of your world at a time then you can just load and store that section of the game world. In that case just about any DB will probably work fine as long as you can quickly query out the objects in that section and quickly write them when you are unloading that section.

With a NoSQL database, you are able to more directly map your application data to your datastore. Object-relational impedance mismatch isn't any issue, and as such you can create a more direct relationship between your application's class design and the schema of your NoSQL database.

Example, for a hypothetical Player class, which may contain complex data structures, attempting to store that data into a relational database would require a complex database schema, as well as complex wrapper classes in the game's actual code base. Almost all of this complexity is removed when storing into a NoSQL datastore. You can develop Entity groups that mirror the structure of your game's Player class.

Using NoSQL for MMOGs is still a fairly new concept, because you do lose complex SQL querying which are critical for game designers, and most NoSQL datastores don't offer transaction support, which is another major omission. That said, be sure CouchDB meets the needs of your game, as choosing the wrong database solution could have dire consequences.

I recently wrote a blog post about why we chose to use Google App Engine as our database solution, and I'll be delving deeper into our actual application design and implementation details in later posts, if you want to keep an eye out for them. Even though we are not using CouchDB, I think you may still find it informative, or at least entertaining ;)