How to Practically Integrate a NoSQL Databases in a Application Currently Build Upon Relational Database

Question

Considering the advantages of NoSQL for Distributed settings and large amount of data/horizontal scalability for fast access, it would make sense that for some implementations a nosql database such as mongodb is a good idea.

However it seems that nosql databases have their advantages and Disadvantages. And it seems that there are clear advantages that relational databases bring to the table, especially for an application that is currently built upon a relational database.

In this context, I would like to ask, are there advantages in standing up two databases, one for the NoSQL types of data and yet a second for other use cases which are predicated by business needs which require relational database type of constraints and features? (Joins, and transactions across tables). And is this a practical and common practice?

As an example, does it make sense that twitter or facebook would have a relational model for user login info and user account versus storing other dynamic data of a NoSQL database?

Answer 1

First, let me say that @Bill Karwin's answer is very thoughtful and I agree with most of what he wrote.

Now, I had an application that evolved over the course of a few years. NoSql wasn't really around when the first generation of the database was created in SQL. The database grew to contain a massive number of tables and an even greater number of functions and stored procedures. Two of us eventually worked full time just to maintain it. Optimizing queries took almost all of my time.

After the first DBA moved on, and I was left alone, I re-designed the concept to use a "NoSql" concept but in the relational DB tables (at that time, Mongo and similar were in alpha/beta). Reduced down to about 10 different tables in this approach. It was moderately successful, but didn't get us much in terms of speed. It did allow us to avoid hiring another DBA though.

The third time around, I implemented a hybrid relational/no-sql data model. Relational was used for the hierarchical data, but kept the same "open table" concept and did not have lots of table columns. Queries were fairly quick, but still not keeping up with our load.

Finally, I decided to ditch the Sql database altogether (about a year ago). I gave up the flexibility of being able to write queries on the fly, but Mongo and Couchbase have enough capability for querying by now that I was comfortable. The performance benefits far outweighed the drawbacks of redundant data in my NoSql application.

My point here is that my case was really best suited to a SQL database, but because of the way I was able to re-design my application, it actually performs better in a NoSql environment, and I can maintain it on my own, part-time, without any help. So, the benefits of a SQL relational database, while powerful, can be very expensive to achieve, and you should factor that into your decision and design.

Answer 2

Yes, of course. And many successful companies do exactly that.

NoSQL database are designed to optimize for access by a specific query load, in much the same way that a denormalized relational database can be designed to help specific queries.

Whereas normalized relational databases are designed to prevent redundant or anomalous storage of data.

Both of these goals are important in the proper context. So there's a place for both relational and non-relational (and denormalized RDBMS fits into the latter category).

The place where either SQL or NoSQL databases can seem suboptimal is when they are inappropriately used for a task where the other would be better.

Purely normalized RDBMS are jack-of-all-trades, master of none in the sense that they support a wide variety of queries. But if you don't need to support a wide variety of queries against a certain dataset, then either denormalized or NoSQL can help.

NoSQL is attractive when you are weary of designing schema and doing ALTER TABLE to add columns from time to time. But you can paint yourself into a corner if you design a NoSQL database for one query load, and then discover you also need to support a totally different query load against the same data. You either suffer with slow queries, or else clone the whole dataset, but stored in a different structure.