Guidelines for Choosing Storage Solutions and Database Types

In daily development, storage solution selection often relies on experience rather than understanding detailed characteristics.

Before choosing a storage engine, consider business and technical metrics such as user volume, data volume, read/write bias, transaction vs. analytical needs, and performance requirements.

Storage Engine Categories and Characteristics

Database Type

Common Databases

Relational

MySQL, Oracle, DB2, SQLServer, etc.

Non‑relational

HBase, Redis, MongoDB, etc.

Row‑store

MySQL, Oracle, DB2, SQLServer, etc.

Column‑store

HBase, ClickHouse, etc.

Distributed

Cassandra, HBase, MongoDB, etc.

Key‑Value

Memcached, Redis, MemcacheDB, etc.

Graph

Neo4J, TigerGraph, etc.

Document

MongoDB, CouchDB, etc.

Relational databases offer easy understanding, powerful SQL, ACID transactions, and stable services, but they face high‑concurrency bottlenecks, heavy index maintenance, limited horizontal scaling, and weak full‑text search.

NoSQL databases complement relational ones. Main types include:

Key‑Value (e.g., Redis) – data resides in memory, O(1) lookups, high read/write throughput, ideal for cache scenarios where reads far exceed writes.

Search (e.g., Elasticsearch) – inverted index enables full‑text search and aggregation, high availability, but requires large memory and has write latency.

Column‑oriented (e.g., HBase) – column‑level reads, space‑saving for sparse data, excellent for massive datasets and analytics; however it depends on Hadoop, is heavy to operate, and lacks flexible queries.

Document‑oriented (e.g., MongoDB) – schema‑less JSON storage, easy field extension, strong read/write performance; drawbacks include limited transaction support, no native joins, and higher storage consumption.

Choosing between relational and NoSQL should be based on data volume, concurrency, real‑time needs, consistency requirements, read/write distribution, security, and operational cost.

Typical system recommendations:

Back‑office management systems – relational databases.

High‑traffic front‑ends – relational DB plus in‑memory cache.

Log‑type systems – column‑store for raw data, search engine for querying.

Search‑driven applications – search engine as front‑end, relational DB as back‑end.

Transactional systems (e.g., inventory, accounting) – relational DB + KV cache + distributed transaction.

Ultimately, storage design must be driven by business requirements, balancing performance, scalability, consistency, and maintenance trade‑offs.