Why NoSQL Beats Relational DBs in Certain Scenarios – A Deep Dive

Relational databases have matured over decades but still have notable drawbacks:

They store row records and cannot directly store complex data structures.

Schema extensions are inconvenient.

Table structures are strongly constrained, making business changes cumbersome.

In big‑data scenarios I/O is high because even column‑only operations require reading whole rows.

Full‑text search relies on LIKE scans, resulting in very low performance.

These shortcomings led to various NoSQL solutions, which can complement SQL in certain scenarios while sacrificing some traditional features.

NoSQL = Not Only SQL

Typical NoSQL solutions are divided into four categories:

Key‑Value stores

Document databases

Columnar databases

Full‑text search engines

1. Key‑Value Store

Redis is a classic example. Its values are concrete data structures such as string, hash, list, set, sorted set, bitmap, hyperloglog, making it a “data‑structure server”.

For a list, the command LPOP key removes and returns the leftmost element.

Implementing the same with a relational database is cumbersome: you must add a position number to each row, query the first row, delete it, and update position numbers for subsequent rows.

Redis’s main drawback is the lack of full ACID transactions; it only guarantees isolation and consistency, not atomicity and durability.

2. Document Database

The key feature is a flexible schema—no predefined fields, and reading a non‑existent field does not cause errors.

Advantages:

Adding new fields is simple.

Historical data remains compatible even without new fields.

Complex data can be stored easily using JSON, far more convenient than relational tables.

For e‑commerce, product attributes vary widely (e.g., refrigerators vs. computers); a document database handles this diversity effortlessly.

Main disadvantages:

No support for transactions.

Cannot perform join operations.

3. Columnar Database

Unlike row‑oriented relational databases, columnar databases store data by column.

Row storage advantages:

Reading multiple columns together is efficient because a single disk I/O loads an entire row.

Writes to multiple columns of the same row are atomic and consistent.

In some scenarios these become disadvantages. For example, calculating average weight only requires the weight column; row storage would still read full rows, wasting I/O.

Columnar storage reads only the needed column, dramatically reducing I/O.

Columnar stores also achieve higher compression ratios (8:1‑30:1) because column data is more homogeneous, compared to row stores (3:1‑5:1).

However, random writes are slower in columnar stores because columns are stored non‑contiguously.

Thus columnar databases are best suited for offline big‑data analytics where operations target a subset of columns and data is mostly read‑only after ingestion.

4. Full‑Text Search Engine

Relational indexes are insufficient for full‑text search, where conditions can be arbitrarily combined and fuzzy matching is required; using LIKE leads to full‑table scans with poor performance.

Consider a dating site with a user table. Queries need to match gender, location, language, or hobbies in many combinations, which relational databases struggle to support efficiently.

Full‑text search engines use inverted indexes to map words to documents, enabling fast keyword‑based retrieval.

The inverted index for the example table would look like:

This makes keyword‑based document queries especially efficient.

Conclusion

The article introduced several typical NoSQL solutions, their applicable scenarios, and characteristics, allowing you to select the most suitable one based on actual requirements.

Content compiled from "From Zero to Architecture".