What types of situations are suited to use both a relational and NoSQL database?

Question

This is not a NoSQL vs. SQL type question. I am interested in types of scenarios where one can use a combination of a RDBMS and NoSQL database and the use of the combination is well suited . In general, I understand the "it depends" on the situation and task at hand, but my thinking is that there must be some general/common ¹ situations where this combination is very useful.

Each of the above types of solutions have there own strengths and weaknesses - what I am after is situations/scenarios where the strengths of both can be fully exploited and utilised.

In my mind, one could be E-commerce. Payments, transactions etc on a RDBMS (think ACID ² ) and product information and catalogues in a NoSQL database. But, is it suitable?

Cross cutting concerns of an application eg. Logging is probably well suited for a NoSQL type solution as another example.

Alternatively, why would you not use both these types of technologies in combination?

Edit: Just to reiterate, I understand that that both SQL and NoSQL have their inherent advantages and disadvantages and that that certain types of situations are more suited to only one of the above data stores.

¹ Iknow the giants like Facebook, Google etc probably use a combination of these, but in almost all most cases I don't think most SO members will ever work on such huge solutions. More typical day-to-day type stuff.

² RavenDB is a NoSQL solution that supports ACID transactions

Answer 1

NOSQL could possibly be used to replicate data from a SQL datastore. In this scenario i want to create documents from mobile SQLITE records, and rely on couch or mongo to replicate this to a nosql on the server. The server SQL can then process the incoming documents.

Answer 2

A good example could be any distributed data store being updated at multiple nodes simultaneously and needing to support potentially complex ad hoc queries. Nodes would be "eventually consistent", which means any particular node might have gaps in its picture of the data at any point in time.

This suits an RDBMS well because the gaps can be handled very simply by "outer" joins between relations. The relational model should be a better fit for this than, say, a graph-based model because the graph model relies on navigational paths between different data elements. If an element is missing then the graph is broken into two graphs and so any path-based query might be invalidated. This problem doesn't exist in the relational model because relational databases are non-navigational - there are no structural "links" between data elements so the "shape" of queries against the data does not need to change just because data is missing.

Answer 3

An obvious answer could be reporting as an example as to where one is more appropriate than the other in a simple application.

For example, you might wish to use a document databae like RavenDB or Couch for your OLTP work, because it gives you the means to save your entities, and query those entities out into flattened projections across documents (single-query views). (RavenDB more than CouchDB, but that's neither here nor there ;-))

You could also use it for simple reporting, using Map/Reduce to give you some statistics for display on certain pages (popular products, tag clouds etc).

However, a lot of reporting systems are built to query relational stores, so you might want to replicate data into a reporting database.

For example, in RavenDB, you have the option to take any index, and automatically replicate the data in that index into a relational store.

It makes sense because having the data in a relational format means you can do complex cross-document queries and integrate with existing reporting products - without getting in the way of the standard OLTP work or the document database design.

This is just one answer out of many, because there are other examples where one particular sort of data store is more suited towards a specific purpose, at the end of the day there is no getting away from that. (Unless you believe the VoltDB guys)

Answer 4

Unless you are operating at a scale where relational databases simply won't work, the big advantage of NoSQL is ease of development - things like not needing an ORM or database upgrade scripts. As soon as you start using SQL for one part of the system it takes very little additional effort to use it for other parts.

In just about any project there will be components that are more suited to a particular type of data store. The important question is whether the difference is enough to justify the overhead of using multiple data stores. Generally that means a combination of scale, ad hoc reporting and data structures that don't map well to a relational database.

Answer 5

It's not really a programming question but here is what I think.

If you consider the CAP theorem http://en.wikipedia.org/wiki/CAP_theorem , you could assume that Relationnal Databases focus on CONSISTENCY and AVAILABILITY while NoSQL focus on AVAILABILITY and PARTITION TOLERENCE (with EVENTUAL CONSISTENCY).

If you espect the SQL query to be really consistent then you should consider using a RDBMS. If it's not a pre-requisite, then you could use a NoSQL database.

That's why most of the time, the best answer it to use both, taking advantages of both.