Re:SQL vs. NoSQL Databases: What’s the Difference?
by djsumdog on Thursday May 12, 2016 @12:36PM
(#11684727)
Articles like this should have, in the opening paragraphs, a statement like, "This is for the general case, there are many outliers." For instance, not all non-relational databases are NoSQL. What about hierarchical databases (LDAP)?
The other thing this article totally fails to address: Why NoSQL was so problematic early on. How Mongo by default would let errors fail silent in Java and other drivers.
She doesn't address the huge limitation in many NoSQL solutions: consistency. She briefly mentions ACID, but neglects the primary use case for document based NoSQL: if your data doesn't need to be current on ever read. So a blog is a great example, or any type of social network really. It really doesn't matter if you're reading a version of the comment thread from 20 seconds ago or 5 seconds ago (as long as it's not like 2 minutes ago).
The author also classifies all NoSQL as document stores, when they're not. Mongo uses a document model/concept, but others may use a model that's more like a distributed memcache or key/value store. There are things like Apache Geode which uses a distributed object store with client based schema versioning. The data model space is pretty big and they're pretty different fundamentally.
The author mentions how a lot of solutions use both, but in other posts I've looked at and other companies I've worked for, I've found that you often have to require both. In a lot of implementations, people use both a NoSQL and a relational store; one more as a fast read cache and the other for long term persistence. Then you get into all the issues with insuring consistency between the two and it's a miss.
Overall, this is a pretty basic article and not one I'd recommend. It can lead to the wrong decision for a project.
The other thing this article totally fails to address: Why NoSQL was so problematic early on. How Mongo by default would let errors fail silent in Java and other drivers.
She doesn't address the huge limitation in many NoSQL solutions: consistency. She briefly mentions ACID, but neglects the primary use case for document based NoSQL: if your data doesn't need to be current on ever read. So a blog is a great example, or any type of social network really. It really doesn't matter if you're reading a version of the comment thread from 20 seconds ago or 5 seconds ago (as long as it's not like 2 minutes ago).
The author also classifies all NoSQL as document stores, when they're not. Mongo uses a document model/concept, but others may use a model that's more like a distributed memcache or key/value store. There are things like Apache Geode which uses a distributed object store with client based schema versioning. The data model space is pretty big and they're pretty different fundamentally.
The author mentions how a lot of solutions use both, but in other posts I've looked at and other companies I've worked for, I've found that you often have to require both. In a lot of implementations, people use both a NoSQL and a relational store; one more as a fast read cache and the other for long term persistence. Then you get into all the issues with insuring consistency between the two and it's a miss.
Overall, this is a pretty basic article and not one I'd recommend. It can lead to the wrong decision for a project.