When should I use a NoSQL database instead of a relational database? Is it okay to use both on the same site?

Question

Relational databases enforces ACID. So, you will have schema based transaction oriented data stores. It's proven and suitable for 99% of the real world applications. You can practically do anything with relational databases.

But, there are limitations on speed and scaling when it comes to massive high availability data stores. For example, Google and Amazon have terabytes of data stored in big data centers. Querying and inserting is not performant in these scenarios because of the blocking/schema/transaction nature of the RDBMs. That's the reason they have implemented their own databases (actually, key-value stores) for massive performance gain and scalability.

NoSQL databases have been around for a long time - just the term is new. Some examples are graph, object, column, XML and document databases.

For your 2nd question: Is it okay to use both on the same site?

Why not? Both serves different purposes right?

NoSQL solutions are usually meant to solve a problem that relational databases are either not well suited for, too expensive to use (like Oracle) or require you to implement something that breaks the relational nature of your db anyway.

Advantages are usually specific to your usage, but unless you have some sort of problem modeling your data in a RDBMS I see no reason why you would choose NoSQL.

I myself use MongoDB and Riak for specific problems where a RDBMS is not a viable solution, for all other things I use MySQL (or SQLite for testing).

If you need a NoSQL db you usually know about it, possible reasons are:

• client wants 99.999% availability on a high traffic site.
• your data makes no sense in SQL, you find yourself doing multiple JOIN queries for accessing some piece of information.
• you are breaking the relational model, you have CLOBs that store denormalized data and you generate external indexes to search that data.

If you don't need a NoSQL solution keep in mind that these solutions weren't meant as replacements for an RDBMS but rather as alternatives where the former fails and more importantly that they are relatively new as such they still have a lot of bugs and missing features.

Oh, and regarding the second question it is perfectly fine to use any technology in conjunction with another, so just to be complete from my experience MongoDB and MySQL work fine together as long as they aren't on the same machine

Martin Fowler has an excellent video which gives a good explanation of NoSQL databases. The link goes straight to his reasons to use them, but the whole video contains good information.

1. You have large amounts of data - especially if you cannot fit it all on one physical server as NoSQL was designed to scale well.

2. Object-relational impedance mismatch - Your domain objects do not fit well in a relaitional database schema. NoSQL allows you to persist your data as documents (or graphs) which may map much more closely to your data model.

NoSQL is database system where data is organised into the document (MongoDB), key-value pair (MemCache, Redis), graph structure form(Neo4J).

Maybe here are possible questions and answer for "When to go for NoSQL":

1. Require flexible schema or deal with tree like data?
   Generally, in agile development we start designing system without knowing all requirement in upfront, where later on throughout development database system may need accommodate frequent design changes, showcasing MVP (Minimal Viable product). Or you are dealing with data schema which is dynamic in nature. e.g. System logs, very precise example is AWS cloudwatch logs.

2. Data set is vast/big?
   Yes NoSQL database are the better candidate for applications where database needs to manage million or even billions of records without compromising over performance.

3. Trade off between scaling over consistency
   Unlike RDMS, NoSQL database may lose small data here and there(Note: probability is .x%), but its easy to scale in terms of performance. Example: This may good for storing people who are online in instant messaging app, tokens in db, logging web site traffic stats.

4. Performing Geolocation Operations: MongoDB hash rich support for doing GeoQuerying & Geolocation operations. I really loved this feature of MongoDB.

In nutshell, MongoDB is great fit for applications where you can store dynamic structured data at large scale.