MongoDB vs MySQL

C++, C#, Java, PHP, ect...
Post Reply
User avatar
a_bertrand
Posts: 1536
Joined: Mon Feb 25, 2013 1:46 pm

MongoDB vs MySQL

Post by a_bertrand »

Hi,

You may have noticed I'm working on a MMORPG fully written in Javascript (some may call it HTML5 but this is misleading, Javascript should be the right term in my opinion). Javascript is by far not my preferred language, yet it allows to run your game on any browser (or nearly) and doesn't require plugins. It has also some advantages like flexible "object" models, where you can add properties and functions any time.

Now, to come back to the title of the thread, I'm investigating how to make the persistence of the game. Basically data will be objects like map areas, monster stats, or even player info. Some data could be aggregated to produce "top players" while others may never be touched on the server side. Since I use node.js on the server side, for convenience, as well as feature set, I must use something which can be linked to node.js (for those not knowing it, it allows you to run JavaScript on the server side, yet with greater features than the normal JavaScript). MySQL can be used, as well as other less known databases like MongoDB which are the kind of NoSQL type. What is it? Basically you don't type SQL statements, and usually those are simply "key => value" pairs stored. No relations or foreign keys. You may think that it's a bit weak, yet for many usage it's good enough.

For example I could store a map with "x-y" as key, and the map data as value. The user could be "username" as key and "user info" being a full object as value etc.

Do any of you used such kind of database? And if yes what's your opinion on it?
Creator of Dot World Maker
Mad programmer and annoying composer
User avatar
Jackolantern
Posts: 10891
Joined: Wed Jul 01, 2009 11:00 pm

Re: MongoDB vs MySQL

Post by Jackolantern »

I really like MongoDB, with one caveat. It is a very interesting take on data storage, and in many ways it feels very liberating. It can add a ton of flexibility to games. For example, say you want to have a boss with a unique ability. That aspect in relational storage would have to take up several different locations: you would have the boss probably in a master monster table with a code under abilities column or something like that referencing another table of abilities where the unique ability actually exists. You know what I am talking about, so you know how convoluted a query can get just to get the ability of a player or creature. As things get more complex, with PvP, player-owned anything, etc., the table relations and queries can get rough.

With a document-oriented database like MongoDB, if you have a special ability that just one boss will have, just add it to them. Simple as that. Everything is stored in a "document" similar to JSON (I think they call it BSON), so you are basically storing up JS objects that anything can be added to and is self-contained. Of course, a real-world game would likely make things a bit more complex than that (see next paragraph), but it is up to the developer how it should be put together. You aren't constantly setting up a complex schema and making tons of references just to keep anomalies from corrupting your database.

However, that one caveat I mentioned. Sometimes NoSQL databases can feel too loose. If you aren't careful and don't plan ahead, you can end up with an unworkable number of "tagged-on" properties that you have no hope of properly making sense of in you code. This issue has somewhat been at least looked in to with some of the node.js modules (and probably modules for other platforms as well) for working with MongoDB, where you actually do create a schema ahead of time. You just have more flexibility in creating it and how you deal with it than you would with MySQL. I believe this is how Mongoose on node.js works.

If you have never checked out a NoSQL database, MongoDB or CouchDB would make great choices. Definitely check one or both out. Are they a relational database killer? Absolutely not. But they are a valuable tool that definitely have their place in your toolbox.
The indelible lord of tl;dr
User avatar
Ark
Posts: 427
Joined: Wed Jun 01, 2011 10:25 pm

Re: MongoDB vs MySQL

Post by Ark »

Mongodb is an awesome database and faster than MySQL. I recommend to use mongo-lite node package which is the easiest way i've found to query with mongodb.
Orgullo Catracho
User avatar
Jackolantern
Posts: 10891
Joined: Wed Jul 01, 2009 11:00 pm

Re: MongoDB vs MySQL

Post by Jackolantern »

Ark wrote:Mongodb is an awesome database and faster than MySQL. I recommend to use mongo-lite node package which is the easiest way i've found to query with mongodb.
Keep in mind that MongoDB is mostly working in-memory, and is only periodically writing to the file system. There are some methods to do that in MySQL, at which point performance gets much closer.
The indelible lord of tl;dr
User avatar
a_bertrand
Posts: 1536
Joined: Mon Feb 25, 2013 1:46 pm

Re: MongoDB vs MySQL

Post by a_bertrand »

If you work with a single key => blob in MySQL and there store your data as json or whatever stream, you end up having basically nearly the same kind of features. However you basically must do all that yourself.

I really like the idea of MongoDB even if in my day to day work I would not need it and actually work with Oracle. For my game on the other side, this idea of document based storage could be exactly what I need.
Creator of Dot World Maker
Mad programmer and annoying composer
User avatar
a_bertrand
Posts: 1536
Joined: Mon Feb 25, 2013 1:46 pm

Re: MongoDB vs MySQL

Post by a_bertrand »

Ok things are progressing with MongoDB, and I starts to have some data in (mainly test data).

What I like:
The flexibility as I can store basically my arrays or objects as it directly inside the databse and recover them with a single query. No transformation not ORB and it seems fast. No I didn't made any benchmark because first there is many on the net, second it's not the main reason I would go away from MySQL.
I like the fact that on the command line tool of mongo, you basically type JS code as commands, therefore you should learn only 1 set of commands.

What is painful:
It's a new world for me. So I need to learn the new commands, understand the tools, see how to make a backup for example.
I also don't know about stability, and no sorry, I don't trust what I can read on the net. Till have my soft up and running for a couple of years, I will not trust it.

What I really don't like:
The JS implementation is painful. Node.JS rely heavily on callbacks. It's a design choice, which yes allows relatively easy multi threading, but with the drawback to make the code quickly a mess. And guess what, MongoDB interface is completely asynchronous, from the connection to the queries all goes through callbacks. It's a pain to work with. Sure there is some tricks / libs to make that a bit more transparent, still it's a pain in my opinion. Mongo command line is synchronous that means I type the command and get the result directly, why do I need to have a different behavior from JS? I know the answer which is linked to the TCP stack of node.js but still it doesn't make it nice to my eyes.
Creator of Dot World Maker
Mad programmer and annoying composer
Post Reply

Return to “Coding”