Is NoSQL a replacement for traditional SQL, or an addition?

Question

I've been reading up on NoSQL, but I can't figure out one thing. Is it meant to be a replacement for traditional SQL, or is it meant to be used in conjunction with it?

Basically, what I'm asking (I think) is: if you have some structured data that could be represented in an SQL database with tables for each kind of object and connections between them (e.g. users, messages, friendships, whatever), are there any advantages / does it make sense to store all of it in a NoSQL database, or should you just store it in a traditional SQL database and use a NoSQL one just for the stuff that needs to be accessed more frequently (e.g. cache)?

Answer 1

NoSQL is for people who are convinced that most of their data is not inter-related so they can just treat them as key value pairs. Same people also think that they can implement data consistency, joins and nested fetches better than proven relational databases, in their favorite language. Of course there were key value databases (like BerkeleyDB, which is bought by Oracle) before the nosql craze. It is just rockstar web developers hadn't noticed before and had to rediscover the concept from scratch as if it was a brand new idea, like 3D, like video, like sockets... I can go on whole day.

In short, it makes sense to store things like http session data and caching trivial stuff in a key value store when you need to squeeze the last drop of performance. But you probably shouldn't bother unless you have measured the performance penalty of taking a simpler approach.

Answer 2

NoSQL movement is there to solve several problems that are harder to solve with traditional RDBMS:

• (buzz) BigData => think TB, PB, etc.. It is not all that trivial to have a TB table and stay performant with RDBMS. In fact, MySQL has a 4TB single table limitation. With NoSQL solutions, this data is usually distributed over many different nodes. Need for storage? Add a node. RDBMS usually solves this by partitioning and clustering, but it is a lot harder to maintain, than for example in Riak.

• Working with Distributed Systems / datasets => say you have 42 products, so 13 of them will live in Chicago datacenter, 21 in NY's and another and 8 somewhere in Japan, but once you query against all 42 products, you would not need to know where they are located: NoSQL DB will. This also allows to engage a lot more brain power ( servers ) to solve hard computational problems.

• Partitioning => having your DB be easily distributed, besides those cool 8 products in Japan, also allows for an easy data replication, so those 42 products will be replicated with a factor of 3, for example, which would mean you DB would have 3 copies for every product. Hence if something goes down, no problem => here is a replica available. This is where NoSQL databases actually shine vs. RDBMS. Granted you can shard, partition and cluster Oracle / MySQL / PostgreSQL / etc.. BUT it is a several magnitudes more complicated process and usually a maintenance headache for most people you'd employ.

However problems where you need 100% consistency, such as most of financial problems, will be a horrible fit for NoSQL, at least today.

Having said all that, MOST of the problems would be solved with a lesser headache with a SQL based solution e.g. PostgreSQL with a Redis cache layer on top of it.

Answer 3

Apart from the above, a great reason to use NoSQL is for caching when building websites. You don't want to keep running complex queries, so you store the results in a NoSQL store. If sh*t hits the NoSQL fan (as detractors often point out, but I am not finding in practice) then design, and structure things so that you can always recover the cache in an emergency by running your cache generation process again over your tables.

You may also find NoSQL very useful for persisting API calls, and even for inter-process communication, since the performance is good enough.