Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I'm a bit confused about the whole NoSQL thing and such. When would you choose to use something like MongoDB over something like Oracle or MySQL? I don't really understand the "difference" as far as usage goes between them.
From my understanding NoSQL type databases aren't meant to replace RDBMSes, but what exactly are they meant to do?
I've used CouchDB before for three pets projects.
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
Sorry to add another answer but none of the answers here are very satisfactory. This answer is specific to MongoDB (as opposed to the vast array of other data storage options out there which are not relational databases).
Update (July 2020)
Every now and then this answer gets a vote and I get a pang of guilt because I've felt for a while it has grown into a stale answer. For one thing, MongoDB supports multi-document transactions now which throws into question a fair number of the points I've brought up. I haven't used it for performance in depth since they added these transactions so I cannot comment on that.
Furthermore, I have recently been working with unstructured data and the schemaless property of MongoDB has been more of a benefit than the below answer might suggest. For example, I am working with test result data generated by a testing & execution solution. The test cases themselves (and thus the different result columns) are created by the end user. MongoDB allowed me to store the free-form test results, in a way that is searchable, without needing a strict schema. I will re-emphasize my point on migration though. Every time the users make a change to their test cases the tools they are using to analyze their results also has to change.
As an alternative, SQL based storage engines have strengthened support for free-form columns such as Postgres' JSONB data type or MySQL's JSON data type.
Take Away: Today, the differences between mongodb and an SQL database feel more and more like the differences between Java & C# or maybe Node & Java. Both have their zealots that will feel the decision is obvious. They both obviously do things differently under the hood. However, at the end of the day its hard to declare either one superior or even to identify broad situations that favor either one.
If you are struggling to make this choice then pick the one that most appeals to you. Keep in mind that any data solution is likely to need to be revisited and rewritten continuously as your application scales up. By then you will understand your storage needs more and will likely be looking for a very tailored critical section / use case.
Pros:
Cons:
Points Often Misunderstood:
To shamelessly steal from Renesis (actually I'm making this answer CW):
Using RDBMS's instead of other types:
Databases like MongoDB are great when you usually know where your data is(as opposed to needing to write several complicated queries). With Mongo, "related" data is either nested in the parent data or it has primary/foreign keys. This is great if, for example, you have Posts and Comments; generally, you aren't going to be displaying comments outside the context of a post, so it makes sense that comments be contained within a post(that way you get all the comments for the post without needing to query a separate table).
MongoDB is schemaless. This means that it will take whatever structure of data you throw at it, for the most part.
On the other hand, if you are need to use aggregate functions and feel the need to query data in complex ways that cannot be achieved through embeds or simple relations in Mongo, that's when you know it's time to use a RDBMS like MySQL or PostgreSQL.
MongoDB isn't meant to replace SQL. It simply fulfills different needs, and MongoDB and an RDBMS can be used in conjunction. In my opinion, MongoDB isn't all that necessary if you don't need your data to be flexible or embedded in a parent document. Development with MongoDB is very fun because there are far fewer steps involved in getting a project(say in Rails) up and running. Need to make a change? No problem. Just add an attribute to your model. Done.
I can't speak for many other NoSQL databases, though I know that they are usually similarly designed to fulfill a specific need that cannot be met by an RDBMS. Some reside entirely in memory or are able to be sharded or scaled very easily. I'm pretty sure that Cassandra is designed to continue operating without data loss if a node goes down. Redis is basically a key value store that resides in memory(with periodic disk writes for persistence), but also has the ability to store data types like sets and sort them.
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).
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.
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.
The immediate and fundamental difference between MongoDB and an RDBMS is the underlying data model. A relational database structures data into tables and rows, while MongoDB structures data into collections of JSON documents. JSON is a self-describing, human readable data format. Originally designed for lightweight exchanges between browser and server, it has become widely accepted for many types of applications.
JSON documents are particularly useful for data management for several reasons. A JSON document is composed of a set of fields which are themselves key-value pairs. This means each JSON document carries its own human readable schema design with it wherever it goes, allowing the documents to easily move between database and client applications without losing their meaning.
JSON is also a natural data format for use in the application layer. JSON supports a richer and more flexible data structure than tables made up of columns and rows. In addition to supporting field types like number, string, Boolean, etc., JSON fields can be arrays or nested sub-objects. This means we can represent a set of sophisticated relations which are a closer representation of the objects our applications work with. Using JSON documents in our database means we don’t need an object relational mapper between our database and the applications it serves. We can persist our data in the right form
If your data needs lots of querying then a NoSQL solution is not good and when you need transactional support (ACID) then a NoSql is not the best fit. I think NoSQL shines when you have a lot of reads which needs to be fast and when the structure is somewhat adhoc, you retrieve by document or by page structure, something like that. But a lots of NoSQL-solutions improves a lot quite fast so there shortcomings maybe soon will be gone. Anyway I think relational databases are still a good fit for most applications.
