When would someone use MongoDB (or similar) over traditional RDMS?

Question

Im a bit confused......the whole NoSQL and such. When would you choose to use something like MongoDB over something like Oracle or MYSQL? I dont really understand....the "difference" as far as usage goes between them.

From my Understanding NoSQL type databases aren't meant to replace RDMS......but what exactly are they meant to do?

Answer 1

I've used CouchDB before for three pets projects.

• A micro blogging system.
• For saving information for a little note taking app I made.
• A general purpose brainstorming application.

The main reason why I chose this over something like MSSQL or MySQL is the flexibility you obtain when using it. No rigid schema. If three months down the line you need a certain table to have an extra field, and this and that, you just change it and it ripples out from there on out.

I used Beginning CouchDB by Apress to learn how to use it.

For example, CouchDB uses json to communicate to/from the database. If your language can POST data, then you can use it to communicate with the DB.

Also read: Why should I use document based database instead of relational database? on StackOverflow

Answer 2

To shamelessly steal from Renesis (actually I'm making this answer CW):

---

Using RDBMS's instead of other types:

• Read up on the idea of "NoSQL" and other DB types:
  • NoSQL: If Only It Was That Easy
  • (above is linked from) When to use MongoDB or other document oriented database systems? (more)
  • Are NoSQL databases going to take the place of relational databases? Is SQL going away?
  • When to use CouchDB vs RDBMS
• RDBMS's make heavy use of indexing for performance. On very large databases, this can have an adverse affect on performance or even reduce the optimal number of rows per DB/Shard requiring more hardware
• Not as ideal if you are storing a massive amount of data but reading less frequently
• If you don't have lots of foreign relationships, relational databases might not be ideal (document storage)

Answer 3

The major win is when you want to shard data or have multi master databases. You can shard data in MySQL but it turns into a major pain. If you are doing a lot of writes it is often useful to shard the data across multiple servers, the problem is that if you want to have strong referential consistency while doing this it can be very hard if not impossible look up CAP theorem.

SQL databases have very good consistency but really bad partitioning support, NoSQL databases tend to go the other way. Easy to partition but often what is called eventual consistency. If you are building a messaging site that is ok, for a bank probably not OK.

The plus is that there are now multiple models to how to store data so there is choice in how you implement stuff, while before all you had were SQL databases.

SE Radio has had a few good episodes on this subject.

Answer 4

When your data is not relational there can be major benefits to using NoSQL databases like performance and scalability (depending on the circumstances, of course). Some design patters like CQRS make it a lot easier to leverage non relational data in areas that would conventionally demand exclusive use of a SQL database.

It is common to use databases like mongo for cached data. For example, if you need to generate a report you could do a complicated SQL query that joins and aggregates a bunch of data on the fly, or you could just fetch a single json document from your mongo database that already has everything you need to generate the report. This makes reading data really easy (and fast!), but can make writing data quite complicated (this is where CQRS comes in).

Answer 5

MongoDB works well when you write a lot of data, and when your querying needs are not too complicated. Therefore, MongoDB is a good fit when you're implementing CQRS with Event Sourcing on the Command side -- i.e., your event store is a MongoDB database.

On the querying side, we still use a SQL Server db with views and WCF Data Services on top, because of its flexibility. I think in most cases you'll really need the power of a relational DB for querying.