I was asking to see if there was any crucial evaluation I had missed putting MongoDB into production.
Below are a few replies to the points you raised:
---------
Data Loss:
Agreed this is a big cloud over the head of MongoDB -
Is it still notorious for this in recent times? Hopefully DBA's for Mongo now have more experience, and the software has matured enough that this isn't a common problem. - or more than it would be for any database.
Even then, you can only fall so far if you take regular backups, and have a fail-over & data recovery plan.
--------
"SQL is hard":
I get your point - a lot of people don't like or understand SQL. However, you seem to lump them with everyone who would appreciate an alternative interface.
Personally, I quite like SQL - some would call me an SQL-ninja. However, I don't think we should be limited to SQL as the one-true-way for accessing data.
Sometimes these new "NoSQL" interface allows new technologies to emerge. For example, the reason MongoDB is being used with Meteor is two-fold:
1. Minimongo - A wholly javascript based mongo query engine. It would be a much harder engineering problem to build a similar tool for SQL / PostgreSQL.
2. Logical Replication - A Meteor instance is effectively a logical replica of the Mongo Database - only for "live" queries, which it interprets using (1)
(1) Means that queries/ their surrounding code can be isomorphic (same on client and server).
To replicate this for SQL would be a huge engineering challenge. How would you even replicate complex joins etc?
(2) Logical replication was only made available in PostgreSQL 9.4 - but without a pluggable query interpreter [even for join-less queries], it still wouldn't work.
----------
Relational Data:
Agreed, that data itself is best decomposed into fully-normalised form (Even up to 6th Normal form if you like temporal data). This allows for single-location, conflict-free and consistent updates/inserts/deletes.
But data usage is inherently document based - and the generation of those documents from fully normalised data, on huge data sets with complex relations, is a massive problem!
Until we have better tools for managing documents made of relational data - eg. PostgreSQL materialised views, but update only invalidated rows, - there will still be a drive to store data (& maintain) in the format that it is read.
I was asking to see if there was any crucial evaluation I had missed putting MongoDB into production.
Below are a few replies to the points you raised:
---------
Data Loss:
Agreed this is a big cloud over the head of MongoDB -
Is it still notorious for this in recent times? Hopefully DBA's for Mongo now have more experience, and the software has matured enough that this isn't a common problem. - or more than it would be for any database.
Even then, you can only fall so far if you take regular backups, and have a fail-over & data recovery plan.
--------
"SQL is hard":
I get your point - a lot of people don't like or understand SQL. However, you seem to lump them with everyone who would appreciate an alternative interface.
Personally, I quite like SQL - some would call me an SQL-ninja. However, I don't think we should be limited to SQL as the one-true-way for accessing data.
Sometimes these new "NoSQL" interface allows new technologies to emerge. For example, the reason MongoDB is being used with Meteor is two-fold:
1. Minimongo - A wholly javascript based mongo query engine. It would be a much harder engineering problem to build a similar tool for SQL / PostgreSQL. 2. Logical Replication - A Meteor instance is effectively a logical replica of the Mongo Database - only for "live" queries, which it interprets using (1)
(1) Means that queries/ their surrounding code can be isomorphic (same on client and server). To replicate this for SQL would be a huge engineering challenge. How would you even replicate complex joins etc?
(2) Logical replication was only made available in PostgreSQL 9.4 - but without a pluggable query interpreter [even for join-less queries], it still wouldn't work.
----------
Relational Data:
Agreed, that data itself is best decomposed into fully-normalised form (Even up to 6th Normal form if you like temporal data). This allows for single-location, conflict-free and consistent updates/inserts/deletes.
But data usage is inherently document based - and the generation of those documents from fully normalised data, on huge data sets with complex relations, is a massive problem!
Until we have better tools for managing documents made of relational data - eg. PostgreSQL materialised views, but update only invalidated rows, - there will still be a drive to store data (& maintain) in the format that it is read.