Btukfyl

With all the hype it seems really hard to find reliable information on when to use this. So I pose the following questions, and I'm sorry if these are really dumb questions in advance:

1. Should I use NoSQL for user data? E.g. profiles, usernames + passwords, etc.


2. Should I use NoSQL for important content? E.g. articles, blog posts, product inventory, etc.

I'm assuming no? And I feel like NoSQL is just for quickly accessible things from which it's OK to lose data. But I also read that NoSQL apps have built-in redundancy so that I don't lose data?

Also if the above 2 examples are bad, could you give me specific business use cases where I would use NoSQL? I see a lot of general descriptions but not a lot of real-world examples. The only things I can think of are user-to-user messaging and analytics.

Thanks!

It really is an "it depends" kinda question. Some general points:

• NoSQL is typically good for unstructured/"schemaless" data - usually, you don't need to explicitly define your schema up front and can just include new fields without any ceremony


• NoSQL typically favours a denormalised schema due to no support for JOINs per the RDBMS world. So you would usually have a flattened, denormalized representation of your data.


• Using NoSQL doesn't mean you could lose data. Different DBs have different strategies. e.g. MongoDB - you can essentially choose what level to trade off performance vs potential for data loss - best performance = greater scope for data loss.


• It's often very easy to scale out NoSQL solutions. Adding more nodes to replicate data to is one way to a) offer more scalability and b) offer more protection against data loss if one node goes down. But again, depends on the NoSQL DB/configuration. NoSQL does not necessarily mean "data loss" like you infer.


• IMHO, complex/dynamic queries/reporting are best served from an RDBMS. Often the query functionality for a NoSQL DB is limited.


• It doesn't have to be a 1 or the other choice. My experience has been using RDBMS in conjunction with NoSQL for certain use cases.


• NoSQL DBs often lack the ability to perform atomic operations across multiple "tables".

You really need to look at and understand what the various types of NoSQL stores are, and how they go about providing scalability/data security etc. It's difficult to give an across-the-board answer as they really are all different and tackle things differently.

For MongoDb as an example, check out their Use Cases to see what they suggest as being "well suited" and "less well suited" uses of MongoDb.

I think Nosql is "more suitable" in these scenarios at least (more supplementary is welcome)

1. Easy to scale by just adding more nodes.



2. 
   

   Query on large data set

   
   
   

   Imagine tons of tweets posted on twitter every day. In RDMS, there could be tables with millions (or billions?) of rows, and you don't want to do query on those tables directly, not even mentioning, most of time, table joins are also needed for complex queries.

   
   


3. 
   

   Disk I/O bottleneck

   
   
   

   If a website needs to send results to different users based on users' real-time info, we are probably talking about tens or hundreds of thousands of SQL read/write requests per second. Then disk i/o will be a serious bottleneck.