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

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 2

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)