95

I'm used to using relational databases like MySQL or PostgreSQL, and combined with MVC frameworks such as Symfony, RoR or Django, and I think it works great.

But lately I've heard a lot about MongoDB which is a non-relational database, or, to quote the official definition,

a scalable, high-performance, open source, schema-free, document-oriented database.

I'm really interested in being on edge and want to be aware of all the options I'll have for a next project and choose the best technologies out there.

In which cases using MongoDB (or similar databases) is better than using a "classic" relational databases? And what are the advantages of MongoDB vs MySQL in general? Or at least, why is it so different?

If you have pointers to documentation and/or examples, it would be of great help too.

Community
  • 1
  • 1
Guillaume Flandre
  • 8,936
  • 8
  • 46
  • 54

8 Answers8

58

Here are some of the advantages of MongoDB for building web applications:

  1. A document-based data model. The basic unit of storage is analogous to JSON, Python dictionaries, Ruby hashes, etc. This is a rich data structure capable of holding arrays and other documents. This means you can often represent in a single entity a construct that would require several tables to properly represent in a relational db. This is especially useful if your data is immutable.
  2. Deep query-ability. MongoDB supports dynamic queries on documents using a document-based query language that's nearly as powerful as SQL.
  3. No schema migrations. Since MongoDB is schema-free, your code defines your schema.
  4. A clear path to horizontal scalability.

You'll need to read more about it and play with it to get a better idea. Here's an online demo:

http://try.mongodb.org/

Kyle Banker
  • 4,359
  • 23
  • 18
  • Mongo offers a very specific path of horizontal scalability, which is useful in specific scenarios.... – AK_ Sep 26 '14 at 17:58
23

There are numerous advantages.

For instance your database schema will be more scalable, you won't have to worry about migrations, the code will be more pleasant to write... For instance here's one of my model's code :

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Adding a key is just adding a line of code !

There are also other advantages that will appear in the long run, like a better scallability and speed.

... But keep in mind that a non-relational database is not better than a relational one. If your database has a lot of relations and normalization, it might make little sense to use something like MongoDB. It's all about finding the right tool for the job.

For more things to read I'd recommend taking a look at "Why I think Mongo is to Databases what Rails was to Frameworks" or this post on the mongodb website. To get excited and if you speak french, take a look at this article explaining how to set up MongoDB from scratch.

Edit: I almost forgot to tell you about this railscast by Ryan. It's very interesting and makes you want to start right away!

Community
  • 1
  • 1
marcgg
  • 65,020
  • 52
  • 178
  • 231
5

The advantage of schema-free is that you can dump whatever your load is in it, and no one will ever have any ground for complaining about it, or for saying that it was wrong.

It also means that whatever you dump in it, remains totally void of meaning after you have done so.

Some would label that a gross disadvantage, some others won't.

The fact that a relational database has a well-established schema, is a consequence of the fact that it has a well-established set of extensional predicates, which are what allows us to attach meaning to what is recorded in the database, and which are also a necessary prerequisite for us to do so.

Without a well-established schema, no extensional predicates, and without extensional precicates, no way for the user to make any meaning out of what was stuffed in it.

Erwin Smout
  • 18,113
  • 4
  • 33
  • 52
  • 1
    This is really an anti-answer. Most meaning, as most people understand it, arises from more than just relational concepts. In fact it is harder for most application developers to discern meaning out of a highly normalized schema than it is for a document store. – user1020853 Mar 01 '15 at 14:43
  • 1
    Meaning, as logic has it, derives from propositions. Propositions can arise from predicates with free places if and when those free places are replaced with actual data items. But those data items must come from a structure. And if there is a structure then there is a schema. Hence if there is no schema, there is no structure that can serve to build propositions that then give rise to meaning, except by sticking one's finger in the air and making one up. That is not anti-anything or pro-anything, it is a simple plain fact. – Erwin Smout Mar 01 '15 at 15:02
  • 3
    That is only one view of meaning and fits only a pretty narrow intellectual context (and it's a philosophical one, not a logical one). Your answer basically reads "if you have no schema like a relational database does, then you have no meaning." That is hardly an answer to the original query of "what are the advantages?" hence I call it an anti-answer. It's also not really true unless we restrict "meaning" down to this narrow context you are coming from. There is plenty of room for "meaning" without a "well-established schema." – user1020853 Mar 01 '15 at 18:24
  • 1
    So how about you show me what your "broader" view of "meaning" is like, and how it can exist without logic's predicates or propositions. Note that my comment did not mention the word "relational" once. Pre-relational data technology had schemas and therefore were suitable to infer "meaning". Pre-database technology had schemas and therefore were suitable to infer "meaning". Schema-free has no schema (unless the "free" part is an outright lie) and therefore isn't suitable to infer "meaning". ... – Erwin Smout Mar 01 '15 at 23:39
  • 1
    ... Schema-free forces its users into a guessing game. And even if those users can manage to get it right 90 or 99% of the time, it's still just that, a guessing game. – Erwin Smout Mar 01 '15 at 23:40
  • I couldn't tell you the number of times I've looked at a db with a well-defined schema and had to guess at the meaning (and been wrong). So there must be something else at play here :) As for the rest, I'm content to let my comments stand and be judged as they are. SO is not conducive to anything else I would need to add in order to elaborate to your satisfaction. – user1020853 Mar 02 '15 at 13:55
  • 1
    Yes there is something else at play. Designers of such databases are using a data model (Codd sense) that explicitly facilitates documenting the intended meaning of the components of their information models, but they neglect to do so. That is not the technology's fault, but its users'. My entire reply still stands, too. Schemas facilitate documenting intended meaning (as well as the enforcement of declared consistency rules), no schema implies neither of both are possible. – Erwin Smout Mar 02 '15 at 15:00
3

My experience with Postgres and Mongo after working with both the databases in my projects .

Postgres(RDBMS)

Postgres is recommended if your future applications have a complicated schema that needs lots of joins or all the data have relations or if we have heavy writing. Postgres is open source, faster, ACID compliant and uses less memory on disk, and is all around good performant for JSON storage also and includes full serializability of transactions with 3 levels of transaction isolation.

The biggest advantage of staying with Postgres is that we have best of both worlds. We can store data into JSONB with constraints, consistency and speed. On the other hand, we can use all SQL features for other types of data. The underlying engine is very stable and copes well with a good range of data volumes. It also runs on your choice of hardware and operating system. Postgres providing NoSQL capabilities along with full transaction support, storing JSON documents with constraints on the fields data.

General Constraints for Postgres

Scaling Postgres Horizontally is significantly harder, but doable.

Fast read operations cannot be fully achieved with Postgres.

NO SQL Data Bases

Mongo DB (Wired Tiger)

MongoDB may beat Postgres in dimension of “horizontal scale”. Storing JSON is what Mongo is optimized to do. Mongo stores its data in a binary format called BSONb which is (roughly) just a binary representation of a superset of JSON. MongoDB stores objects exactly as they were designed. According to MongoDB, for write-intensive applications, Mongo says the new engine(Wired Tiger) gives users an up to 10x increase in write performance(I should try this), with 80 percent reduction in storage utilization, helping to lower costs of storage, achieve greater utilization of hardware.

General Constraints of MongoDb

The usage of a schema less storage engine leads to the problem of implicit schemas. These schemas aren’t defined by our storage engine but instead are defined based on application behavior and expectations.

Stand-alone NoSQL technologies do not meet ACID standards because they sacrifice critical data protections in favor of high throughput performance for unstructured applications. It’s not hard to apply ACID on NoSQL databases but it would make database slow and inflexible up to some extent. “Most of the NoSQL limitations were optimized in the newer versions and releases which have overcome its previous limitations up to a great extent”.

ProgrammerPanda
  • 1,566
  • 1
  • 12
  • 16
2

It's all about trade offs. MongoDB is fast but not ACID, it has no transactions. It is better than MySQL in some use cases and worse in others.

AABBCCDD
  • 57
  • 1
1

Bellow Lines Written in MongoDB: The Definitive Guide.

There are several good reasons:

  1. Keeping different kinds of documents in the same collection can be a nightmare for developers and admins. Developers need to make sure that each query is only returning documents of a certain kind or that the application code performing a query can handle documents of different shapes. If we’re querying for blog posts, it’s a hassle to weed out documents containing author data.
  2. It is much faster to get a list of collections than to extract a list of the types in a collection. For example, if we had a type key in the collection that said whether each document was a “skim,” “whole,” or “chunky monkey” document, it would be much slower to find those three values in a single collection than to have three separate collections and query for their names
  3. Grouping documents of the same kind together in the same collection allows for data locality. Getting several blog posts from a collection containing only posts will likely require fewer disk seeks than getting the same posts from a collection con- taining posts and author data.
  4. We begin to impose some structure on our documents when we create indexes. (This is especially true in the case of unique indexes.) These indexes are defined per collection. By putting only documents of a single type into the same collection, we can index our collections more efficiently
Nanhe Kumar
  • 15,498
  • 5
  • 79
  • 71
0
  1. MongoDB supports search by fields, regular expression searches.Includes user defined java script functions.
  2. MongoDB can be used as a file system, taking advantage of load balancing and data replication features over multiple machines for storing files.
user2982063
  • 1
0

After a question of databases with textual storage), I glanced at MongoDB and similar systems.
If I understood correctly, they are supposed to be easier to use and setup, and much faster. Perhaps also more secure as the lack of SQL prevents SQL injection...
Apparently, MongoDB is used mostly for Web applications.
Basically, and they state that themselves, these databases aren't suited for complex queries, data-mining, etc. But they shine at retrieving quickly lot of flat data.

PhiLho
  • 40,535
  • 6
  • 96
  • 134
  • 1
    There's a couple of mis-conceptions in your answer. While MongoDB isn't vulnerable to SQL injection, it is susceptible to injection more generally. You can specify arbitrary Javascript in the $where clause of a query. Also, unlike a lot of the other NoSQL option, MongoDB can actually do some pretty complex queries. – Emily Jan 22 '10 at 21:29
  • Thanks for the precisions. Note that, as I stated, it is the MongoDB site itself that emitted restrictions on relational queries. Unless I misunderstood something else... – PhiLho Jan 23 '10 at 14:40
  • It seems quite likely that they said MongoDB is unsuited for complex relational queries, but for complex non-relational queries, it's quite well-suited. Take a look at http://www.mongodb.org/display/DOCS/Advanced+Queries for some of the cool stuff you can do. – Emily Jan 26 '10 at 22:42