Introduction to NoSQL and NoSQL Business Drivers

3.1 Introduction to NoSQL and Business Drivers

Recall first

“NoSQL” does not mean “no query language.” What problem is a NoSQL system usually optimizing, and what relational guarantee or convenience might it trade away?

First principles

NoSQL is a family of non-relational data stores organized around different models and access patterns: key-value, document, wide-column, and graph. It is not one database and not one consistency model. Cassandra, MongoDB, and HBase therefore cannot be treated as interchangeable products.

NoSQL systems became attractive when applications needed some combination of:

• horizontal scale by adding nodes;
• high write/read throughput and predictable key-based access;
• flexible or evolving record shapes;
• availability across failures or regions;
• very large data volumes and event rates;
• a data model closer to the application’s access pattern.

These are business drivers, not automatic reasons to discard SQL. Relational databases remain strong for multi-row transactions, rich joins, declarative constraints, and mature reporting. A NoSQL choice is justified by a workload and an explicitly accepted trade-off.

The central design shift

Relational design often normalizes shared facts and lets joins reconstruct a view. NoSQL design often starts with the query: what key will be known, what data must be returned together, and how will it partition? Denormalization or duplication may make a read fast, but it shifts work to writes, consistency repair, and schema evolution.

For example, Cassandra’s official architecture describes partitioned key-oriented queries and explicitly avoids cross-partition transactions, distributed joins, foreign keys, and referential integrity (Cassandra architecture). That is a deliberate trade-off for scalable, highly available partitioned access—not a missing feature to ignore.

CAP and consistency, carefully

In a network partition, a distributed system cannot simultaneously guarantee both unrestricted availability and strong consistency for every operation. NoSQL systems make different choices and often expose tunable or eventual consistency. Eventual consistency means replicas may temporarily disagree but converge if updates stop and repair succeeds; it does not mean “random” or “always stale.” The exact guarantees are product- and operation-specific.

Always distinguish:

• availability: whether the system responds during failures;
• consistency: what values a read is permitted to observe;
• durability: whether acknowledged data survives failure;
• latency: how quickly the response arrives.

Worked choice

A social-feed service needs to fetch posts by user_id, append new posts, and remain available during a region outage. A wide-column or key-value design may partition by user and time bucket. It may duplicate author display data to avoid joins. The team must then handle hot users, bucket rollover, stale duplicated names, and cross-user feed queries. A relational design may be better if the workload requires complex joins and strict multi-row transactions.

Exercise — revealed answer

Exercise: Is “schema flexibility” sufficient by itself to choose MongoDB, Cassandra, or HBase?

Answer: No. Ask which access pattern, partition key, latency, consistency, update, and failure requirements dominate. Flexible fields describe one property of some systems; they do not decide the architecture.

Exam lens

Define NoSQL as a family, name four models, give three business drivers, then state one trade-off. A high-scoring answer says model and partition key follow access patterns and compares consistency/availability rather than repeating “NoSQL is faster.”

Rapid revision checklist

• Define NoSQL as a family, not one product.
• Name horizontal scale, availability, flexible schema, and key-based throughput as drivers.
• Contrast normalization/joins with access-pattern-oriented denormalization.
• Distinguish consistency, availability, durability, and latency.
• State that a workload—not a slogan—selects the database.

Key takeaways

1. NoSQL trades some relational generality for scale, availability, flexibility, or access-pattern performance.
2. The partition key is an architectural decision, not just an index choice.
3. “NoSQL” includes systems with very different models and guarantees.

Sources

• Apache Cassandra architecture and guarantees.
• MongoDB data modeling.
• Apache HBase reference guide.
• Mining of Massive Datasets.
• Syllabus-aligned supplement: the business-driver and CAP vocabulary is an exam-oriented synthesis connecting the listed NoSQL text to official system documentation; guarantees must be checked for the chosen product/version.