129

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?

33

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

  • 31
    Your first two examples sounds like a good domain for a traditional Relational DBMS. – Jonas Jul 8 '11 at 10:57
  • 4
    @yati: That kind of application sounds similar to StackOverflow.com and I find it works very good with a traditional relational database. – Jonas Sep 19 '11 at 14:08
  • 4
    @yatisagade: I we are not talking about dynamic social sites. But a little note taking app and a micro blogging system. – Jonas Sep 19 '11 at 14:56
  • 2
    How is not having a defined schema ever a plus? With a relational DB, if three months down the line you need an extra field, you just add the field. With a relational DB you can't add a field dynamically but you also can't change your application code dynamically to work with a dynamically added field. – Solomonoff's Secret Jun 6 '16 at 21:20
  • 9
    This answer seem to suggest the schema of a relational database cannot be changed. I am unable to comprehend what amount of misunderstandings which might lead someone to believe this. It is trivial to add a new column in a relational database. Typically there is a nice UI, or if you prefer to script it, it can be done in a single SQL statement. – JacquesB Dec 12 '16 at 15:04
14

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).

Pros:

  • MongoDB has a lower latency per query & spends less CPU time per query because it is doing a lot less work (e.g. no joins, transactions). As a result, it can handle a higher load in terms of queries per second and is thus often used if you have a massive # of users.
  • MongoDB is easier to shard (use in a cluster) because it doesn't have to worry about transactions and consistency.
  • MongoDB has a faster write speed because it does not have to worry about transactions or rollbacks (and thus does not have to worry about locking).
  • MongoDB does not have a schema in case you have a special use case that can take advantage of that.

Cons:

  • MongoDB does not support transactions. This is how it obtains most of its benefits.
  • In general, MongoDB creates more work (e.g. more CPU cost) for the client server. For example, to join data one has to issue multiple queries and do the join on the client.
  • Even here in 2017 there is less tooling support for MongoDB than there is for relational databases simply because it is newer. There are also fewer MongoDB experts than their relational counterparts.

Points Often Misunderstood:

  • Both MongoDB and relational databases support indexing. Their query performance is similar in terms of executing large queries.
  • MongoDB does not remove the need for migrations or more specifically, updating your existing data as your schema evolves. For example: If you have an application that relies on a users table to contain certain data, and you modify that table to contain different data (let's say you add a profile picture field), then you will still need to either:
    • Write you application to handle objects for which this property is undefined OR
    • Write a one-time migration to put in a default value for this property OR
    • Write code to provide a default value at query time if this field is not present OR
    • Handle the missing field in some other way
  • 2
    I'd add a huge thing, that is somehow missed in many NoSQL vs RDBMS discussion: NoSQL databases are much harder for ad-hoc querying (that's the "no SQL part". This is true whether you are a developer or not. Therefore, they are also much harder to create reports with, which is crucial to any serious business. – Michael Nov 15 '17 at 11:36
  • Heh, I'd almost call that a feature for MongoDB as I discourage that kind of interaction with my databases. However, Mongo does have an ad-hoc query language and a graphical ad-hoc client (Compass). It isn't as feature rich as SQL so I will agree it is a potential shortcoming but for me personally, it will never make a difference when I am deciding which database to use. – Pace Nov 15 '17 at 16:16
  • Why would you discourage exploring the data in your database? If this database has any useful information for the business, it ought to be as accessible as possible. Obviously while not adding load unto production, that's what you have read replicas for. – Michael Nov 15 '17 at 20:24
  • This is probably an interesting question in its own right and I imagine many people would have different points of view. Personally I avoid it because it becomes a maintenance issue. I create web applications and expose REST APIs that I commit to maintaining and optimizing for performance. I've been in situations where I cannot make wholesale changes to the database because it would break too many sales engineers' query scripts and I try to avoid that scenario now. E.g. I just recently part of my db from PostgreSQL to Cassandra for high scale performance and didn't have to change my API. – Pace Nov 15 '17 at 22:14
  • Eventually you will always have stakeholders that are interested in looking at the data. Whether it's via a SQL query or some kind of ipython notebook script, or via re:dash. So when you make database changes, you will always have to make sure you don't break these dependencies. SQL (not RDBMS) makes the data more accessible, and for a that's a good thing for a business. – Michael Nov 16 '17 at 12:14
12

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


Using RDBMS's instead of other types:

  • 4
    "RDBMS's make heavy use of indexing for performance" Isn't indexing used with MongoDB as well? – Rotareti Oct 19 '16 at 15:41
  • When to use MongoDB or other document oriented database systems? currently deleted on SO... no more .. have reopened the question as well protected it. Not sure the reasoning behind deletion. – Rahul Mar 20 '17 at 14:07
9

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).

7

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.

6

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.

  • It has to be remembered that sharding is heavily dependent on the architecture of your data centre. If you have a server rack its performance is awesome. On distributed DCs, not so much. Agreed on what you say about the general ease of partioning on NoSql DBs --but reliability is a key concern. – Apoorv Khurasia Nov 16 '12 at 21:03
  • If you do a lot of writes you may simply have 2 models: a denormalized stronly indexes read model AND an unindexed write model. Naturally replication is needed which adds complexity. You'll have to evaluate what is more disadvantageous for you: coping with NoSQL limitations i.e. do a lot more programming work yourself to match records in the java domain, or have existing DB replication technology do the work or you which will cost more on terms of configuration and hardware. – Lawrence May 15 '17 at 13:46
1

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.

  • If you write a lot of data won't global write locks negatively affect you? – Apoorv Khurasia Nov 16 '12 at 21:01
  • 1
    Note that Mongodb no longer uses a global write lock (and had already been updated to not require one when the above comment was posted). – Jules Sep 3 '15 at 1:26
1

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

1

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.

protected by gnat Jul 24 '16 at 0:23

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?