MongoDB or MySQL for a complex browser game on Rails_问答_开发者

I am implementing a browser based game with a small group of friends using RoR, meant to be deployed on Heroku. We were implementing everything regarded to databases on MySQL. However, Heroku's free/cheap MySQL databases are shared and inefficient, and there is no intermediate level; the dedicated ones are pretty expensive for our start. Therefore, we started considering the MongoDB solutions that are provided, which are much more accessible, when considering prices.

However, our application will have lots of tables, with lots of relations and foreigns keys. For instance, we will have tables for attacks, for units present in those attacks, for every tile in the map and what is inside it, and among others.

Therefore, would there be any performance issue or problem on using MongoDB? I know that, although it can create relationships between its collections, it is not mean 100% for that, right? Should we stick with a bad and shared MySQL database until we can afford a dedicated one, or there is no need for them, and we can stick with MongoDB with no big issues?

Consider that we will have a lot of queries and updates, and all of them will probably r开发者_StackOverflow社区eference relationships between different tables/collections.

I work with both mySQL and mongoDB for different applications.

When we're working with an object oriented structure we generally go mongoDB over mySQL due to the nature of it's design of mongoDB being object oriented.

When we're requiring more relational data (like user profiles, friendships and messages as an example) we go with mySQL as it is definitely better for relational data.

My team finds that the first week or so with mongoDB is a bit tough (as most are so used to mySQL) but after that they generally prefer it to work with, for example no predefined schema's are required, just get started with the collection. The order of data in mongoDB must be respected ALOT more than in mySQL also. So you're aware, we're using a jQuery AJAX with JSON structure over PHP with mongoDB for the current application we're working on.

Maintenance and admin wise, much of a muchness, but mongoDB does struggle more if SOMEONE (I'm not naming names Pablo), forgets to index something. We did have a monogDB server crash a couple of weeks due to this. I restarted the server and again crashed, so I had to re-route all traffic to another temporary server that was about to go online as a back-up server for mongoDB, because of this everything was in place for the new server to take the place of the existing server temporarily luckily. When I started the server with no queries, found the problem, added the index and as soon as I added it and put it back online the processors went from insanely high to normal, no problems since.

Personally I tend to try to be a little more proactive with mongoDB because the issues that come up can be more severe than mySQL, in what happened with our crash, mySQL probably would have experience slowness but mongoDB in the same situation did crash completely.

I like them both though and will use them both moving to the future but the right choice and doing the basics is really important, more so for mongoDB in my opinion.

I hope this extra insight helps a little.

Rather impossible to answer. Only you and your team know your data model and know if it can fit into a nested, hierarchical, document.

Just because you have alot of foreign key constraints, tables, JOINs, etc does not mean that you cannot change the entire data model to work with MongoDB (or any other NoSQL for that matter), but you'll probably need to do quite a bit of work to change your data model and access patterns.

Unfortunately, like I said above, we don't know if that is possible with your current application design.

Check out http://www.mongodb.org/display/DOCS/Schema+Design and http://www.slideshare.net/kbanker/mongodb-schema-design

An application that depends on a lot of highly relational data probably shouldn't be implemented with a non-relational database.