MongoDB vs MySQL

Question

I used to build Ruby on Rails apps with MySQL.

MongoDB currently become more and more famous and I am now starting to give it a try.

The problem is, I don't know the underlying theory of how MongoDB is working (am using mongoid gem if it matter)

So I would like to have a comparison on the performance between using MySQL+ActiveRecord and model generated by mongoid gem, could anyone help me to figure it out?

Solution 1

The article entitled: What the heck are you actually using NoSQL for? does a very good job at presenting the pros and cons of using NoSQL.

Edit: Also read http://blog.fatalmind.com/2011/05/13/choosing-nosql-for-the-right-reason/ blog post too

Re-edit: I found some recent material (published in 2014) on this topic that I consider to be relevant: What’s left of NoSQL?

Solution 2

I don't know much of the underlying theory. But this is the advice I got: only use MongoDB if you run it across multiple servers; that's when it'll shine. As far as I understand, the NoSQL movement appeared in no small part due to the pain of load-balancing relational databases across multiple servers. So if you're hosting your application on no more than one server, MySQL would be the preferred choice.

The good people over at the Doctrine project recently wrote a quite useful blog post on the subject.

Solution 3

From what I have read so far... here is my take on it.

Standard SQL trades lower performance for feature richness... i.e. it allows you to do Joins and Transactions across data sets (tables/collections if you will) among other things.

This allows a application developer to push some of the application complexity into the database layer. This has it's advantages of not having to worry about data integrity and the rest of the ACID properties by the application by depending upon proven technology. The lack of extreme scalability works for pretty much all projects as long as one can manage to keep the application working within expected time limits, which may sometimes result in having to purchase high performance/expensive relational database systems.

On the other hand, Mongo DB, deliberately excludes much of the inherent complexity associated with relational databases, there by allowing for better scalable performance.

This approach forces the application developer to re-architect the application to work around the lack of relational features... which in and itself is a good thing, but the effort involved is generally only worth it if you have the scalability requirements. Please note that with MongoDB depending upon the data requirements w.r.t ACID properties, the application will have to step up and handle as necessary.

Comments

[PeterWong]

Is there any feature in MongoDB making it more suitable for multiple servers?

[Henrik]

Much like many search solutions, MongoDB uses "sharding". It's a way of splitting ranges of data across multiple servers. Also, since MongoDB lacks many of the data integrity features of relational databases, it should be run on no less than two servers (a master and a slave). en.wikipedia.org/wiki/MongoDB

[Michael J.V.]

Relational databases support sharding. NoSQL solutions don't support transactions and often fail in the flushing records to disk. Good luck in using them where data consistency is a must.

[Matthew Setter]

It doesn't get in to the details or specifics of when to use one NoSQL implementation over the other, as the title would suggest, however the case is made quite well. Don't use something just because you can or it's the latest trend or buzz word/term/technology. Maybe the tool that you have works perfectly well, but you're not using it right. As the saying goes: A bad workman blames his tools. Either way, the moral of the story is spot on.

[jdc0589]

@Michael J.V : sorry, but your data consistency point is just incorrect

[johndodo]

Note that MongoDB has other advantages (and disadvantages) too. For instance schema design is quite different, you can put files in your DB,... Deciding whether to use it just on number of hosts is not enough. Even if you host on just one server there are some very valuable advantages to using MongoDB. Biggest disadvantage imho is shortage of hosting plans with MongoDB integrated (the way MySQL usually is).

[wprl]

As @MattSetter says, don't use something just because you can or because it's trendy. I will add this: most data is not strongly relational- or document-based and MongoDB is very easy to scale.

[wprl]

MongoDB supports map-reduce, another feature that takes advantage of multiple servers.

[wprl]

You are right in general, but I'd like to point out that Mongo is "mostly" ACID compliant on the document level. Joins are the devil. Both of those potential pitfalls are made less problematic by planning database design to avoid the need for joins or writes to more than one document. Schema definition is done in the app, but can be done using libraries, so it's not too different from defining your schemata in e.g. a hibernate.xml file (exept, as you say, that schema definitions are enforced in the app, not in the database).