Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

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

share|improve this question

migrated from stackoverflow.com Oct 10 '11 at 11:12

This question came from our site for professional and enthusiast programmers.

1  
It sounds like someone hasn't done basic research. Not a "real question". (NoSQL only means "No SQL" while this often means that relationships are ... less important ... it is not always the case. Consider neo4j or Tutorial D are also "No SQL" databases). –  pst Oct 8 '11 at 22:47
2  
Actually it means "Not Only SQL" and embraces polyglot persistence. See the article by Martin Fowler (martinfowler.com/bliki/PolyglotPersistence.html). And there is a range from NOSQL stores handling large amounts of simple data to NOSQL stores handling complex, rich data (skillsmatter.com/podcast/nosql/…) –  Michael Hunger Nov 18 '11 at 5:58

3 Answers 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.