The agenda of this blog is simple. We’ll discuss various parameters that we keep in mind while deciding a perfect database for our Application Service.
In terms of data engineering, data pressure is the ability of the system to process the amount of data at a reasonable cost or a reasonable time. When one of those dimensions is broken, that’s a technology trigger and new inventions happen that result in new data technologies. In simple terms …
SQL is not obsolete, it’s just that now we have a different choice.
Before we jump up to comparing SQL and NoSQL databases, let’s take some time to appreciate the fact that SQL has been long into the industry (over 30+ years) and still has a good place in the modern application development environment.
SQL: Optimized for Storage
NoSQL: Optimized for Compute/Querying
SQL: Table based data structure
NoSQL: Depending on DBs, the data structures are …
★ Key-Values(DynamoDB, Redis, Voldemort)
★ Wide-column i.e. containers for rows(Cassandra, HBase)
★ Collection of Documents(MongoDB, CouchDB, DynamoDB)
★ Graph Structures(Neo4J, InfiniteGraph)
SQL: Ad hoc queries
NoSQL: Instantiated views
SQL: Scale Vertically & Expensive. Can Scale Horizontally but challenging & time-consuming
NoSQL: Scale Horizontally & Cheap
SQL: Fixed schema, altering requires modifying the whole database
NoSQL: Schemas are dynamic
SQL: Good for OLAP
NoSQL: Good for OLTP at scale
SQL: ACID(Atomicity, Consistency, Isolation, Durability) properties
NoSQL: BASE(Basically Available, Soft state, Eventual consistency) properties
For our application service, when it comes down to ...
✔ Well-known and well-understood types of access patterns
✔ Want simple queries
✔ Not much data calculation involved
✔ Have a common business process
✔ OLTP apps
If this is true, then NoSQL is a perfect Database and would be most efficient. We have to structure the data model specifically to support the given access pattern.
If our application service has the requirements to support ...
✔ Ad-hoc queries. e.g. bi analytics use case or OLAP application
✔ May require “reshaping” the data
✔ Complex queries, inner joins, outer joins, etc.
✔ Complex value calculations
So in brief, for our application service, if we understand the access patterns very well, they’re repeatable, they’re consistent, and scalability is a big factor, then NoSQL is a perfect choice.
PS: Mature developers don’t use the word “flexible” for NoSQL databases. There is a difference in being dynamic and flexible. Data model design is an intelligent engineering exercise in NoSQL databases.
What your opinion over my discussion up here? Why do you choose NoSQL over SQL?
Thanks for reading this blog!
Add a ❤ if you liked the comparison. Leave a comment below if you have any questions/feedback. I'm gonna write a Series on DynamoDB here, follow me for updates.
More About Author: Om Bharatiya
Happy Coding <3