When selecting databases, I would really recommend getting an understanding of how they all fit in and are related to eachother.
All database types have their merit. So I wouldn't bash on mongodb vs mysql or any other for that matter. The selection of the right database type is entirely based on your own use cases and future use cases.
Whilst CAP theorem is out dated it is important to understand why it came about and the point it was trying to make: en.wikipedia.org/wiki/CAP_theorem
Then there is the discussion about the 3'Vs of data, which will allow you to understand whether right now or even in the future will you be dealing with "big data" and therefore do you need to adjust your technology now or later to meet these requirements: whatis.techtarget.com/definition/3Vs
When it comes to SQL vs NOSQL or even more exotic database structures it is important to understand how brands try to claim they cover all the bases, but ultimately they will all have something they can not do. Whilst SQL databases typically drop you into a relational world, there are "families" of non-relational databases. Selection of the right family is purely down to the use case.
As an example, whilst you may know of MongoDB, Cassandra, Neo4j as being non-relational databases each of these fall within specific families. There's a bunch of them ranging from:
Column stores
Key value stores
Document stores
Graph relational
Each of them have a specific use case and its important to understand when one should be used over another. For a good breakdown of this information take a look over this: jamesserra.com/archive/2015/04/typ...
Remember, just because google are using spanner and pinterest are using Cassandra, does not mean you need to be using it in your latest project. It also does not mean you need to pick 1.
To give some context to my statement you may find that you want a flexible schema database that you will iterate your front end client application numerous times during your build. Typically the data to be stored requires little in the way of joins and the queries you need to execute are simplistic. Your front end would benefit from receiving all the data in one request and is happy enough to work against a REST API. In this scenario you may say a document store would work quite well, like MongoDB.
Later on in your project you realise you wish to provide text searching across a number of collections within MongoDB and provide site wide search for products including the usage of fuzzy matching, auto completion and "did you mean" type scenarios. In this instance a text search database, potentially based on the lucene engine like Solr or Elasticsearch may serve you best. Yes, you could use MongoDB for this, but you may find you are starting to push complex query and join logic into a database that is typically trying to remain simplistic.
When selecting databases, I would really recommend getting an understanding of how they all fit in and are related to eachother.
All database types have their merit. So I wouldn't bash on mongodb vs mysql or any other for that matter. The selection of the right database type is entirely based on your own use cases and future use cases.
Whilst CAP theorem is out dated it is important to understand why it came about and the point it was trying to make: en.wikipedia.org/wiki/CAP_theorem
Then there is the discussion about the 3'Vs of data, which will allow you to understand whether right now or even in the future will you be dealing with "big data" and therefore do you need to adjust your technology now or later to meet these requirements: whatis.techtarget.com/definition/3Vs
When it comes to SQL vs NOSQL or even more exotic database structures it is important to understand how brands try to claim they cover all the bases, but ultimately they will all have something they can not do. Whilst SQL databases typically drop you into a relational world, there are "families" of non-relational databases. Selection of the right family is purely down to the use case.
As an example, whilst you may know of MongoDB, Cassandra, Neo4j as being non-relational databases each of these fall within specific families. There's a bunch of them ranging from:
Each of them have a specific use case and its important to understand when one should be used over another. For a good breakdown of this information take a look over this:
jamesserra.com/archive/2015/04/typ...
Remember, just because google are using spanner and pinterest are using Cassandra, does not mean you need to be using it in your latest project. It also does not mean you need to pick 1.
To give some context to my statement you may find that you want a flexible schema database that you will iterate your front end client application numerous times during your build. Typically the data to be stored requires little in the way of joins and the queries you need to execute are simplistic. Your front end would benefit from receiving all the data in one request and is happy enough to work against a REST API. In this scenario you may say a document store would work quite well, like MongoDB.
Later on in your project you realise you wish to provide text searching across a number of collections within MongoDB and provide site wide search for products including the usage of fuzzy matching, auto completion and "did you mean" type scenarios. In this instance a text search database, potentially based on the lucene engine like Solr or Elasticsearch may serve you best. Yes, you could use MongoDB for this, but you may find you are starting to push complex query and join logic into a database that is typically trying to remain simplistic.
Thanks for that insight, I feel that this will help me make the right choice. :)