🗄️ 一文看懂当下主流数据库：从关系型、NoSQL 到 DDB / DynamoDB 的全景认知地图

在技术博客、架构图、技术分享中，我们经常看到一长串数据库名词：

MySQL、PostgreSQL、Redis、MongoDB、ClickHouse、Elasticsearch、Neo4j、Milvus、TiDB、DynamoDB、DDB、华为 V5……

很多人用过其中一两个，却很难回答一个更本质的问题：

现在到底有多少”数据库类型”？
以及：为什么有些东西”看起来像数据库”，却又不像 MySQL 那样清晰？

这篇文章的目标不是教你语法，也不是选型细节，而是：

帮你建立一张”数据库世界观地图”——
知道每一类数据库、每一种叫法，究竟解决什么问题、处在什么层级。

一、数据库的本质：我们到底在解决什么问题？

抛开所有名词，数据库本质只回答三件事：

1. 数据如何存

结构化数据：有固定格式，如表格数据（用户表、订单表）
半结构化数据：有结构但不固定，如 JSON、XML
非结构化数据：无固定格式，如文本、图片、视频

2. 数据如何查

精确查询：根据主键或唯一标识查询单条记录
范围查询：查询某个范围内的数据
聚合分析：统计、求和、分组等分析操作
全文搜索：在文本内容中搜索关键词
相似度搜索：找到相似的数据（如向量相似度）

3. 数据如何扩展

并发能力：同时处理多少请求
存储容量：能存多少数据
分布式：如何跨多台机器存储和查询
高可用：如何保证服务不中断

所有数据库的差异，本质都是在这三点上的取舍。

二、关系型数据库（RDBMS）：最经典、最稳妥的一类

全称： Relational Database Management System

核心概念

关系型数据库基于 关系模型 （Relational Model），数据以 表（Table） 的形式组织，表由 行（Row） 和 列（Column） 组成。

代表数据库

MySQL：最流行的开源关系型数据库，适合中小型应用
PostgreSQL：功能最强大的开源数据库，支持复杂查询和扩展
Oracle：企业级数据库，功能强大但商业授权
SQL Server：微软的数据库产品，与 Windows 生态集成好

核心特征

表结构（Schema）：数据必须符合预定义的表结构
SQL 语言：使用标准化的 SQL 语言操作数据
ACID 事务：保证数据一致性的四个特性
- Atomicity（原子性）：事务要么全部成功，要么全部失败
- Consistency（一致性）：事务前后数据保持一致
- Isolation（隔离性）：并发事务互不干扰
- Durability（持久性）：事务提交后数据永久保存
关系约束：外键、唯一约束、非空约束等

为什么重要

关系型数据库是业务系统的”真账本”，几乎所有核心业务数据都存储在关系型数据库中。它提供了最强的数据一致性和事务保证，是金融、电商、企业系统的基础。

适合场景

业务系统核心数据：用户、订单、账户、支付
需要强一致性：账户余额、库存数量
复杂查询：多表关联、复杂业务逻辑
事务处理：需要保证数据一致性的操作

局限

横向扩展困难：难以通过增加机器来提升性能
不擅长海量分析：聚合查询性能有限
Schema 变更成本高：修改表结构需要停机或复杂迁移
不适合非结构化数据：存储 JSON、文本等不够灵活

代码示例

-- 创建用户表
CREATE TABLE users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) UNIQUE NOT NULL,
    email VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 插入数据
INSERT INTO users (username, email) VALUES ('alice', 'alice@example.com');

-- 查询数据
SELECT * FROM users WHERE username = 'alice';

-- 事务示例
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;
COMMIT;

👉 一句话总结：业务系统的”真账本”，几乎永远离不开关系型数据库。

三、NoSQL 数据库：为扩展性而生的一大类

全称： Not Only SQL

核心概念

NoSQL = Not Only SQL，不是不用 SQL，而是不被 SQL 限制。NoSQL 数据库放弃了关系型数据库的一些特性（如 ACID 事务、固定 Schema），换取了更好的扩展性和性能。

为什么需要 NoSQL

大数据量：关系型数据库难以处理 PB 级数据
高并发：需要支持百万级 QPS
灵活 Schema：业务快速迭代，数据结构经常变化
分布式：需要跨多台机器存储和查询

1️⃣ Key-Value 数据库

全称： Key-Value Store

代表数据库

Redis：内存型 Key-Value 数据库，性能极高
Memcached：简单的内存缓存
DynamoDB：AWS 的托管 Key-Value 数据库
Etcd：分布式配置存储

核心特点

数据结构：Key → Value，最简单的数据模型
查询方式：只能通过 Key 查询，不支持复杂查询
性能：查询路径极短，性能极高
用途：缓存、Session、分布式锁、计数器

详细解释

Key-Value 数据库是最简单的 NoSQL 数据库，数据以键值对的形式存储。就像字典一样，通过 Key 直接找到 Value，没有复杂的查询逻辑。

Redis 示例：

import redis

r = redis.Redis(host='localhost', port=6379)

# 设置值
r.set('user:1:name', 'Alice')
r.set('user:1:email', 'alice@example.com')

# 获取值
name = r.get('user:1:name')  # b'Alice'

# 计数器
r.incr('page:views')  # 自增
views = r.get('page:views')

DynamoDB 示例：

import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Users')

# 写入数据
table.put_item(
    Item={
        'user_id': '123',
        'username': 'alice',
        'email': 'alice@example.com'
    }
)

# 查询数据
response = table.get_item(Key={'user_id': '123'})

应用场景

缓存：缓存热点数据，减少数据库压力
Session 存储：存储用户会话信息
分布式锁：实现分布式系统的互斥
计数器：实时统计、点赞数、浏览量
消息队列：简单的消息队列（Redis List）

优缺点

✅ 优点：性能极高、简单易用、支持丰富的数据结构（Redis）
❌ 缺点：不支持复杂查询、数据关系难以表达、内存限制（Redis）

👉 Redis 是”内存里的瑞士军刀”
👉 DynamoDB 是”云上的 Key-Value 数据库”

2️⃣ 文档型数据库（Document DB）

全称： Document Database

代表数据库

MongoDB：最流行的文档数据库
CouchDB：支持多主复制的文档数据库
Firestore：Google 的文档数据库

核心特点

数据结构：JSON / BSON 文档，类似嵌套的 JSON 对象
Schema 灵活：每个文档可以有不同结构
查询能力：支持复杂查询，但不如 SQL 强大
适合场景：内容管理、配置数据、快速迭代的业务

详细解释

文档数据库将数据存储为文档（通常是 JSON 格式），每个文档可以有不同的结构。这比关系型数据库更灵活，适合数据结构经常变化的场景。

MongoDB 示例：

// 插入文档
db.users.insertOne({
    username: "alice",
    email: "alice@example.com",
    profile: {
        age: 25,
        city: "Beijing"
    },
    tags: ["developer", "python"]
})

// 查询文档
db.users.findOne({ username: "alice" })

// 复杂查询
db.users.find({
    "profile.age": { $gt: 20 },
    tags: "developer"
})

应用场景

内容管理系统：博客、CMS、Wiki
用户配置：用户偏好、个性化设置
日志存储：应用日志、操作日志
快速原型：业务模型快速迭代

优缺点

✅ 优点：Schema 灵活、开发快速、支持嵌套数据
❌ 缺点：事务支持弱、复杂查询性能差、数据冗余

3️⃣ 列族数据库（Wide-Column）

全称： Wide-Column Store / Column Family Database

代表数据库

HBase：基于 HDFS 的列族数据库
Cassandra：分布式列族数据库
ScyllaDB：高性能 Cassandra 替代品

核心特点

数据模型：按列族存储，类似”超级宽表”
高写入吞吐：适合大量写入场景
天然分布式：设计时就考虑分布式
适合场景：日志、时间序列、IoT 数据

详细解释

列族数据库将数据按列族（Column Family）组织，而不是按行。这就像把 Excel 表格转置，按列存储。这种设计让写入性能极高，适合大量写入的场景。

HBase 数据模型：

Row Key    | Column Family:cf1          | Column Family:cf2
           | col1    | col2    | col3    | col1    | col2
-----------|---------|---------|---------|---------|--------
user:001   | value1  | value2  | value3  | value4  | value5
user:002   | value6  | value7  | value8  | value9  | value10

应用场景

日志存储：应用日志、访问日志
时间序列数据：监控指标、传感器数据
IoT 数据：设备上报数据
消息系统：消息存储和查询

优缺点

✅ 优点：写入性能极高、天然分布式、适合大数据量
❌ 缺点：查询复杂、不支持复杂事务、学习成本高

四、分析型数据库（OLAP）：为”看数据”而生

全称： Online Analytical Processing

核心概念

OLAP 与 OLTP（Online Transaction Processing，在线事务处理）不同：

OLTP：处理日常业务操作，如下单、支付（写多读少）
OLAP：处理数据分析查询，如统计、报表（读多写少）

代表数据库

ClickHouse：列式存储，分析查询极快
Doris：百度开源的 OLAP 数据库
Greenplum：基于 PostgreSQL 的 MPP 数据库
Snowflake：云原生的数据仓库

核心特点

列式存储：按列存储数据，而不是按行
聚合查询快：SUM、COUNT、GROUP BY 等操作极快
压缩率高：相同类型的数据压缩效果好
不适合频繁更新：写入性能较差

为什么需要 OLAP

当数据量达到 TB 甚至 PB 级别时，关系型数据库的聚合查询会变得非常慢。OLAP 数据库通过列式存储和并行计算，让分析查询快几个数量级。

列式存储 vs 行式存储

行式存储（OLTP）：
Row1: [id:1, name:Alice, age:25, city:Beijing]
Row2: [id:2, name:Bob, age:30, city:Shanghai]
Row3: [id:3, name:Charlie, age:28, city:Beijing]

列式存储（OLAP）：
Column id:    [1, 2, 3]
Column name:  [Alice, Bob, Charlie]
Column age:   [25, 30, 28]
Column city:  [Beijing, Shanghai, Beijing]

优势：

查询只需要读取需要的列
相同类型的数据压缩效果好
聚合操作（SUM、AVG）可以并行计算

应用场景

数据仓库：企业数据仓库、BI 分析
实时分析：实时报表、Dashboard
日志分析：分析大量日志数据
用户行为分析：用户画像、行为统计

代码示例

-- ClickHouse 示例
CREATE TABLE user_events (
    user_id UInt64,
    event_type String,
    event_time DateTime,
    properties String
) ENGINE = MergeTree()
ORDER BY (user_id, event_time);

-- 分析查询
SELECT 
    event_type,
    count() as cnt,
    uniq(user_id) as users
FROM user_events
WHERE event_time >= today() - 7
GROUP BY event_type
ORDER BY cnt DESC;

👉 一句话：OLTP 管”做事”，OLAP 管”看事”。

五、搜索引擎型数据库：查”内容”，不是查字段

代表数据库

Elasticsearch：最流行的搜索引擎
OpenSearch：Elasticsearch 的开源分支
Solr：Apache 的搜索引擎

核心特点

倒排索引：建立词到文档的映射，而不是文档到词
全文搜索：在文本内容中搜索关键词
模糊匹配：支持拼写错误、同义词
相关性排序：根据相关性排序结果

详细解释

搜索引擎数据库的核心是倒排索引（Inverted Index）。传统索引是”文档 → 词”，倒排索引是”词 → 文档”，这样搜索时可以直接找到包含关键词的文档。

倒排索引示例：

文档1: "I love Python"
文档2: "Python is great"
文档3: "I love Java"

倒排索引：
"i"      → [文档1, 文档3]
"love"   → [文档1, 文档3]
"python" → [文档1, 文档2]
"is"     → [文档2]
"great"  → [文档2]
"java"   → [文档3]

为什么需要搜索引擎

关系型数据库的 LIKE 查询性能很差，无法支持全文搜索、模糊匹配、相关性排序等需求。搜索引擎专门解决这些问题。

应用场景

全文搜索：网站搜索、内容搜索
日志分析：ELK Stack（Elasticsearch + Logstash + Kibana）
商品搜索：电商网站的商品搜索
内容推荐：根据内容相似度推荐

代码示例

from elasticsearch import Elasticsearch

es = Elasticsearch(['localhost:9200'])

# 创建索引
es.indices.create(index='articles', body={
    'mappings': {
        'properties': {
            'title': {'type': 'text'},
            'content': {'type': 'text'},
            'author': {'type': 'keyword'}
        }
    }
})

# 插入文档
es.index(index='articles', body={
    'title': 'Python 入门教程',
    'content': 'Python 是一种高级编程语言...',
    'author': 'Alice'
})

# 搜索
result = es.search(index='articles', body={
    'query': {
        'match': {
            'content': 'Python 编程'
        }
    }
})

👉 它更像”可查询的数据索引系统”，而不是传统意义上的数据库。

六、图数据库：关系本身就是数据

代表数据库

Neo4j：最流行的图数据库
JanusGraph：分布式图数据库
ArangoDB：多模型数据库（支持图）

核心特点

数据模型：节点（Node）+ 边（Edge）+ 属性（Property）
关系查询：高效查询节点间的关系
图遍历：快速遍历图的路径
适合场景：社交网络、推荐系统、知识图谱

详细解释

图数据库将数据存储为图结构，节点表示实体，边表示关系。这种模型非常适合表达复杂的关系网络。

图数据库示例：

节点：
- User(id:1, name:Alice)
- User(id:2, name:Bob)
- Movie(id:1, title:Titanic)

边：
- (User:1) -[:FRIENDS_WITH]-> (User:2)
- (User:1) -[:LIKES]-> (Movie:1)
- (User:2) -[:LIKES]-> (Movie:1)

为什么需要图数据库

关系型数据库用 JOIN 查询关系，当关系深度增加时，性能急剧下降。图数据库专门优化了关系查询，可以高效地查询多度关系。

查询示例：

// Neo4j Cypher 查询语言
// 查找 Alice 的朋友的朋友喜欢的电影
MATCH (alice:User {name: 'Alice'})-[:FRIENDS_WITH]->(friend)-[:FRIENDS_WITH]->(friendOfFriend)-[:LIKES]->(movie)
RETURN DISTINCT movie.title

应用场景

社交网络：好友关系、关注关系
推荐系统：基于关系的推荐
知识图谱：实体关系查询
风控系统：关系链分析、反欺诈

优缺点

✅ 优点：关系查询极快、表达复杂关系直观
❌ 缺点：不适合简单查询、学习成本高、生态不如关系型数据库

七、时间序列数据库（TSDB）

全称： Time Series Database

代表数据库

InfluxDB：专门的时间序列数据库
Prometheus TSDB：Prometheus 的时序存储
TimescaleDB：基于 PostgreSQL 的时序数据库

核心特点

时间是第一维度：数据按时间组织
高写入性能：支持大量时间序列数据写入
生命周期管理：自动删除过期数据
压缩优化：针对时间序列数据优化压缩

详细解释

时间序列数据库专门存储按时间顺序排列的数据，如监控指标、传感器数据、股票价格等。数据通常有固定的时间间隔（如每秒、每分钟）。

数据模型：

时间序列：
timestamp          | metric_name | value
2024-01-01 10:00:00 | cpu_usage  | 45.2
2024-01-01 10:00:01 | cpu_usage  | 46.1
2024-01-01 10:00:02 | cpu_usage  | 44.8

应用场景

监控系统：服务器监控、应用监控
IoT 数据：传感器数据、设备数据
金融数据：股票价格、交易数据
日志分析：按时间分析日志

代码示例

from influxdb_client import InfluxDBClient

client = InfluxDBClient(url="http://localhost:8086", token="token")
write_api = client.write_api()

# 写入数据
point = Point("cpu_usage")\
    .tag("host", "server1")\
    .field("value", 45.2)\
    .time(datetime.utcnow())

write_api.write(bucket="monitoring", record=point)

# 查询数据
query = 'from(bucket:"monitoring") |> range(start: -1h) |> filter(fn: (r) => r._measurement == "cpu_usage")'
result = client.query_api().query(query)

八、向量数据库：AI 时代的新物种

代表数据库

Milvus：开源向量数据库
Pinecone：托管的向量数据库
Weaviate：向量搜索引擎
FAISS：Facebook 的向量相似度搜索库

核心能力

存储向量：存储高维向量（Embedding）
相似度搜索：快速找到相似的向量
语义检索：基于语义相似度的搜索
AI 应用：RAG、推荐系统、图像搜索

详细解释

向量数据库专门存储和查询向量数据（通常是 AI 模型生成的 Embedding）。它使用向量相似度算法（如余弦相似度、欧氏距离）来找到相似的向量。

向量搜索示例：

from pymilvus import connections, Collection

# 连接 Milvus
connections.connect("default", host="localhost", port="19530")

# 创建集合
collection = Collection("embeddings")

# 插入向量
vectors = [[0.1, 0.2, 0.3, ...], [0.4, 0.5, 0.6, ...]]
collection.insert(vectors)

# 相似度搜索
search_vectors = [[0.15, 0.25, 0.35, ...]]
results = collection.search(
    data=search_vectors,
    anns_field="vector",
    param={"metric_type": "L2", "params": {"nprobe": 10}},
    limit=10
)

为什么需要向量数据库

AI 应用（如 RAG、推荐系统）需要存储和搜索大量的向量数据。传统数据库无法高效地进行向量相似度搜索，向量数据库专门优化了这个问题。

应用场景

RAG 系统：存储文档向量，实现语义检索
推荐系统：基于向量相似度推荐
图像搜索：以图搜图
语义搜索：基于语义的文本搜索

👉 一句话：向量数据库是 AI 系统的”长期记忆”。

九、新一代分布式数据库：试图”什么都要”

代表数据库

TiDB：兼容 MySQL 的分布式数据库
CockroachDB：兼容 PostgreSQL 的分布式数据库
YugabyteDB：兼容 PostgreSQL 和 Cassandra

目标

SQL 兼容：支持标准 SQL
分布式：自动分片、自动扩容
高可用：自动故障恢复
强一致性：支持 ACID 事务

详细解释

新一代分布式数据库试图同时拥有关系型数据库的 SQL 能力和 NoSQL 数据库的扩展能力。它们通过分布式架构实现横向扩展，同时保持 SQL 接口和 ACID 事务。

TiDB 架构：

应用层
  ↓
TiDB Server (SQL 层，无状态)
  ↓
TiKV (存储层，分布式 KV)
  ↓
PD (调度层，元数据管理)

为什么需要

传统关系型数据库难以横向扩展，NoSQL 数据库不支持 SQL 和复杂事务。新一代分布式数据库试图兼顾两者。

现实挑战

架构复杂：需要管理多个组件
运维成本高：需要专业的运维团队
性能权衡：分布式带来延迟和一致性权衡
生态不成熟：工具和生态不如传统数据库

应用场景

大规模业务系统：需要 SQL 和扩展性
多租户 SaaS：需要数据隔离和扩展
全球化应用：需要多地部署

十、到这里为止，都是”数据库引擎”

那 DDB、华为 V5、DynamoDB 又是什么？

这是很多人真正困惑的地方。我们需要理解数据库的分层架构：

【应用层】
   ↓
【数据库平台/治理层】← DDB、华为 V5 在这里
   ↓
【数据库引擎层】← MySQL、DynamoDB、Redis 在这里
   ↓
【存储层】

十一、DynamoDB：原生分布式数据库（引擎层）

全称： Amazon DynamoDB

详细解释

DynamoDB 是一个真正的数据库产品，由 AWS 提供，是一个数据库引擎。

核心特点

Key-Value / Wide-Column：支持两种数据模型
Serverless：无需管理服务器，按使用量付费
自动分区：自动分片，无需手动管理
高可用：多可用区部署，自动故障转移
全球表：支持多区域复制

技术背景

DynamoDB 源自著名的 Dynamo 论文（2007 年 Amazon 发表），核心设计理念是：

牺牲复杂查询，换取极致可用性和扩展性。

数据模型

# DynamoDB 表结构
Table: Users
Primary Key: user_id (String)
Attributes:
  - username (String)
  - email (String)
  - created_at (Number)

# 写入数据
table.put_item(
    Item={
        'user_id': '123',
        'username': 'alice',
        'email': 'alice@example.com',
        'created_at': 1704067200
    }
)

# 查询数据（只能通过主键或索引）
response = table.get_item(Key={'user_id': '123'})

适用场景

高并发应用：需要支持百万级 QPS
Serverless 应用：与 Lambda 函数配合
全球应用：需要多区域部署
简单数据模型：Key-Value 或简单的宽表

优缺点

✅ 优点：Serverless、自动扩展、高可用、全球部署
❌ 缺点：查询能力有限、成本较高、厂商锁定

📌 DynamoDB 属于：数据库引擎层的 NoSQL 数据库

十二、DDB：不是数据库，而是”数据库平台层”

全称： Distributed Database Service / 分布式数据库服务

详细解释

DDB 不是数据库引擎，而是数据库平台/治理层。它通常是一个中间件或服务层，提供数据库的统一访问、分库分表、高可用等功能。

架构层次

应用层
  ↓
DDB 访问层 / 治理层  ← DDB 在这里
  ├── 分库分表路由
  ├── 读写分离
  ├── 连接池管理
  ├── 监控告警
  └── 统一配置
  ↓
MySQL / PostgreSQL  ← 真正的数据库引擎

核心功能

分库分表：自动将数据分散到多个数据库
路由：根据规则路由查询到正确的数据库
读写分离：读请求路由到从库，写请求路由到主库
高可用：自动故障转移、主从切换
统一管理：统一的配置、监控、运维

为什么需要 DDB

当单个数据库无法支撑业务时，需要：

分库分表：将数据分散到多个数据库
读写分离：提升读性能
高可用：保证服务不中断

DDB 将这些能力封装成服务，让应用无需关心底层细节。

实现方式

中间件方式：如 ShardingSphere、MyCat
代理方式：如 ProxySQL、MaxScale
SDK 方式：在应用层实现路由逻辑

关键点

DDB 不定义数据模型：底层仍然是 MySQL、PostgreSQL 等
DDB 不替代数据库引擎：它只是管理和路由
DDB 解决的是：如何规模化、统一地使用数据库

示例

# 使用 DDB SDK（伪代码）
from ddb import DDBClient

client = DDBClient(config={
    'sharding_key': 'user_id',
    'databases': ['db1', 'db2', 'db3']
})

# 写入数据（自动路由到正确的数据库）
client.insert('users', {
    'user_id': 12345,
    'username': 'alice',
    'email': 'alice@example.com'
})

# 查询数据（自动路由）
user = client.query('users', {'user_id': 12345})

十三、华为 V5：工程代际，而非数据库类型

详细解释

“V5”不是数据库分类，而是华为内部基础平台/数据平台的第五代成熟方案代号。

通常包含

数据库：如 GaussDB（华为的数据库产品）
存储：分布式存储系统
中间件：消息队列、缓存等
高可用与容灾：备份、恢复、容灾方案
运维平台：监控、告警、自动化运维

本质

它更接近 “数据库基础设施体系” 或 “数据平台”，而不是单一的数据库产品。

类似概念

阿里云数据库服务：RDS、PolarDB、AnalyticDB
腾讯云数据库服务：CDB、TDSQL
AWS 数据库服务：RDS、DynamoDB、Aurora

这些都是数据库平台/服务层，提供数据库的统一管理和服务化能力。

十四、把所有名词放回同一张地图

数据库分层架构全景图

┌─────────────────────────────────────────┐
│  应用层                                  │
│  (业务代码、API、服务)                    │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│  数据库平台/治理层                        │
│  • DDB (分布式数据库服务)                 │
│  • 华为 V5 数据平台                      │
│  • 阿里云数据库服务                      │
│  • 内部 XDB / 数据库服务                 │
│  (分库分表、路由、高可用、监控)           │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│  数据库引擎层                             │
│  ┌─────────────┬─────────────┬────────┐ │
│  │ 关系型数据库  │ NoSQL 数据库 │ 其他   │ │
│  ├─────────────┼─────────────┼────────┤ │
│  │ MySQL       │ Redis       │ ES     │ │
│  │ PostgreSQL  │ MongoDB     │ Neo4j  │ │
│  │ Oracle      │ DynamoDB    │ Milvus │ │
│  │ SQL Server  │ HBase       │ ...    │ │
│  └─────────────┴─────────────┴────────┘ │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│  存储层                                  │
│  (磁盘、SSD、分布式存储)                  │
└─────────────────────────────────────────┘

分类总结表

层级	代表产品	本质	解决的问题
平台/治理层	DDB、华为 V5	数据库服务化	如何规模化使用数据库
引擎层-关系型	MySQL、PostgreSQL	数据库引擎	结构化数据、ACID 事务
引擎层-Key-Value	Redis、DynamoDB	数据库引擎	高性能缓存、简单查询
引擎层-文档型	MongoDB	数据库引擎	灵活 Schema、JSON 数据
引擎层-列族	HBase、Cassandra	数据库引擎	大数据量写入
引擎层-OLAP	ClickHouse、Doris	数据库引擎	分析查询、数据仓库
引擎层-搜索引擎	Elasticsearch	数据库引擎	全文搜索、日志分析
引擎层-图数据库	Neo4j	数据库引擎	关系查询、图遍历
引擎层-时序	InfluxDB	数据库引擎	时间序列数据
引擎层-向量	Milvus	数据库引擎	向量相似度搜索