Disclaimer: I'm an idiot and don't make great architectural decisions.<p>The two main things to think about are simplicity and scale. As for the former, key-value stores from the basic BerkeleyDB (though I think there's more modern and better software now) up to three-dimensional bigtables are really conceptually simple when it comes to your data. It's (mostly) a blob, and it's got a key. Couldn't be easier. Of course, when it comes to using the data, once you want to add new uses it becomes harder because now you have to write actual code in a procedural language and that's usually not very efficient. That's where the power of relational databases comes in. Very very easy there to use the data in a new way you hadn't envisioned easily. It's just a matter of a different SQL query!<p>Then there's scale. Most people don't <i>really</i> have this problem. Think about the point where you want to stop using sqlite in favor of a separate-process database like Postgresql or MySQL. That's a difficult spot to pinpoint, right? But you have a general idea of where it is. The time where you can't scale postgresql out and start needing a lot of Cassandra or Accumulo servers is a good order of magnitude farther than that. It would really be premature optimization to worry about it before you know it's going to be a problem. Especially since once you cross that bridge, you lose out on scale in a different dimension: querying and using the data becomes tougher!<p>I haven't really talked about hierarchical schemaless structures like MongoDB because I don't really like them / don't really think they're that useful. Sorry!
That is an exceptionally broad topic. NoSQL is a pretty large category of database that is pretty much anything that is not "SQL". These include just about everything from document stores, object stores, caches, and columnar stores. So, it depends on what have in data.<p>Most people talk about Mongo when it comes to NoSQL. Mongo is a very nice, high availability, document store. It has eventual consistency and can be horizontally scaled in a number of ways. I won't go into all of the uses but one I can think of is in an environment with very very high read with extremely low writes where you need low latency on reads and a document based data structure.<p>To answer this thoroughly would require quite a bit of time to build a curriculum around the various types of NoSQL stores, what their strengths and weaknesses are, and how to know whether your data fits. In other words, it's a big topic.
There are a lot of different kinds of NoSQL databases, and they have different usage scenarios.<p>For example a key/value store like Cassandra is very different from a schemaless hierarchical structure found within MongoDB. They're both NoSQL, but extremely different from one another.<p>I'd only suggest you study the different options so you'll know if a specific NoSQL (or SQL) database solution is a good fit for your projects.
<a href="https://www.youtube.com/watch?v=qI_g07C_Q5I" rel="nofollow">https://www.youtube.com/watch?v=qI_g07C_Q5I</a>
In this video Martin Fowler have some recommendations
of when to choose a relational, graph or noSql database.
When you need more than one server to run your database.<p>The main different between NoSQL/SQL DBMS is about auto scaling. NoSQL scales well on multiple servers, as they were designed to work that way, while SQL dbs do not.