其他 NoSQL 数据库总结

关系型数据库并不擅长解决所有数据存储问题。面对海量数据、动态字段、全文检索、复杂关系查询和水平扩展等特殊需求，需要选择更合适的 NoSQL 数据库。

一、核心主线

关系型数据库并不擅长解决所有数据存储问题。面对海量数据、动态字段、全文检索、复杂关系查询和水平扩展等特殊需求，需要选择更合适的 NoSQL 数据库。

本节介绍了四类典型 NoSQL 数据库：

1
2
3
4
5
6
7

文档数据库：解决数据结构灵活、Schema 经常变化的问题

列式数据库：解决海量写入、按少数列进行分析的问题

全文搜索数据库：解决关键词检索和复杂搜索的问题

图数据库：解决实体关系的存储、查询和分析问题

最后引出 NewSQL：尝试把 NoSQL 的可扩展性与关系型数据库的事务能力结合起来。

二、文档数据库

1. 基本原理

文档数据库的典型代表包括：

• MongoDB；
• CouchDB。

文档数据库通常使用 JSON 或类似文档格式保存数据，而不是强制使用固定的行、列结构。

示例：

1
2
3
4
5

{
  "name": "手机",
  "memory": "12GB",
  "battery": "5000mAh"
}

另一类商品可以拥有完全不同的字段：

1
2
3
4
5

{
  "name": "衬衫",
  "size": "L",
  "material": "棉"
}

文档数据库与键值数据库比较相似，可以把一份完整文档看作某个 Key 对应的 Value。

2. 核心优势

• 不依赖僵硬、固定的表结构；
• Schema 扩展相对灵活；
• 不同文档可以拥有不同字段；
• 适合存储结构复杂或不断变化的数据；
• 通常具有较好的水平扩展能力。

3. 适用场景

• 数据量很大，并且增长速度很快；
• 数据字段定义不明确；
• 字段经常变化，难以建立统一 Schema；
• 不同对象拥有不同属性。

典型例子是商品参数：

• 电子产品包含内存、电池容量等参数；
• 服装包含尺码、面料等参数；
• 不同商品类型很难共用完全一致的表结构。

4. 不适用场景

按照本节给出的选型思路，文档数据库不适合：

• 强依赖跨文档事务的业务；
• 需要频繁执行复杂关联查询的业务；
• 大量依赖关系型数据库 JOIN 的场景。

三、列式数据库

1. 行式存储与列式存储

关系型数据库通常按行存储数据：

1

学号 | 姓名 | 性别 | 班级 | 专业

每条记录的全部字段被放在一起。

列式数据库则按列组织数据：

1
2
3

学号列：205100, 205101, 205102...
姓名列：张三, 李四, 王五...
专业列：计算机, 计算机, 材料...

典型代表包括：

• BigTable；
• HBase。

2. 查询效率优势

假设需要统计各专业的学生人数。

行式数据库通常需要读取完整记录：

1

学号 + 姓名 + 性别 + 班级 + 专业

但真正参与统计的只有“专业”一列，其他字段的读取产生了额外磁盘 I/O。

列式数据库只需要读取“专业”列：

1
2
3
4
5

读取专业列
   ↓
执行 Group By
   ↓
得到各专业人数

因此，针对少数列的统计和分析，列式存储可以显著减少磁盘 I/O。

3. 数据压缩优势

同一列的数据类型通常相同，并且可能包含大量重复值，因此更容易压缩。

例如，可以使用字典编码：

1
2
3
4
5
6
7
8

性别字典：
0 → 男
1 → 女

专业字典：
0 → 计算机
1 → 材料
2 → 土木工程

原来的字符串可以被替换成较短的数字编号。

数据量越大、重复值越多，压缩带来的空间收益通常越明显。

4. 适用场景

• 海量数据持续写入，但修改很少；
• 用户行为、日志、埋点等数据收集；
• 离线数据分析；
• 只针对少数几列进行统计；
• 需要较高压缩率的海量数据存储。

5. 不适用场景

• 数据需要高频删除或修改；
• 直接服务于大量在线事务请求；
• 强依赖事务能力；
• 经常需要读取一条记录的全部字段。

四、全文搜索数据库

1. 为什么需要全文搜索数据库

全文搜索数据库的典型代表是 Elasticsearch。

关系型数据库可以通过 LIKE 进行模糊匹配，但这类查询可能需要扫描大量数据，处理海量文本时效率较低。

全文搜索数据库通过倒排索引提高关键词检索效率。

2. 倒排索引

普通文档存储关注的是：

1

文档 → 文档中有哪些词

倒排索引则反过来维护：

1

关键词 → 关键词出现在哪些文档中

示例：

1
2
3
4

五一 → 文档1、文档5
热门 → 文档1、文档4
北京 → 文档2、文档3
游戏 → 文档4

搜索某个关键词时，可以直接通过索引找到相关文档，而不需要扫描全部文档内容。

3. 索引记录的信息

倒排索引中的文档列表可以包含：

• 文档 ID；
• 关键词出现频率；
• 关键词出现位置；
• 其他用于相关性计算的信息。

这些数据不仅能用于查找文档，还可以支持搜索结果排序。

4. 适用场景

• 搜索引擎；
• 站内关键词搜索；
• 海量数据的复杂查询；
• 日志检索；
• 数据统计和聚合。

5. 不适用场景

• 数据需要高频更新；
• 强依赖事务；
• 要求索引与原始数据始终保持严格同步。

全文搜索数据库修改数据时，往往相当于删除旧文档并创建新文档，因此更新成本通常高于简单读取。

五、图数据库

1. 基本原理

图数据库并不是用来存储图片的数据库，而是使用“图”这种数据结构组织数据。

典型代表包括：

• Neo4j；
• Titan。

图主要由两个元素组成：

例如学生选课系统可以表示为：

1
2

学生 ──选课──> 课程
教师 ──任教──> 课程

2. 核心优势

• 能够自然、直观地表达实体关系；
• 关系是一等公民，不需要依赖大量中间表；
• 容易沿关系查找相邻节点；
• 适合处理多跳关系查询；
• 解决关系型数据库不擅长的复杂关系分析问题。

3. 适用场景

• 社交网络；
• 好友、关注和粉丝关系；
• 知识图谱；
• 推荐系统；
• 风控关系网络；
• 路径分析；
• 强调实体关系的复杂查询。

六、NewSQL

1. NewSQL 出现的背景

不同 NoSQL 数据库解决了关系型数据库在扩展性、灵活结构、全文检索和复杂关系处理等方面的问题。

但传统 NoSQL 往往会弱化或放弃：

• 强一致性；
• 完整事务能力；
• 关系型查询能力。

NewSQL 的目标是结合两类数据库的优势：

1
2
3
4
5

关系型数据库的事务和一致性
             +
NoSQL 的分布式扩展能力
             ↓
           NewSQL

典型项目包括：

• Google Spanner；
• TiDB；
• CockroachDB。

2. 底层存储

NewSQL 底层通常仍然使用分布式键值存储系统保存数据。

在此基础上增加关系型数据库所需的能力。

3. 关键技术

3.1 LSM Tree

底层键值存储系统可以采用 LSM Tree，提高高并发写入性能。

3.2 细粒度分片

NewSQL 不再只使用传统的整库主从复制，而是将数据拆分为更细粒度的分片。

每个分片都可以独立：

• 存储数据；
• 复制数据；
• 进行故障转移；
• 在节点之间迁移。

3.3 分布式共识

主从分片之间可以通过 Paxos、Raft 等分布式共识算法复制数据。

其目标是：

• 保证多个副本之间的数据一致性；
• 避免单点故障；
• 在部分节点异常时继续提供服务。

3.4 分布式事务

NewSQL 在分布式键值存储之上实现分布式事务，使跨节点、跨分片操作也能具备事务能力。

4. 优势与局限

优势

• 保留 NoSQL 较强的水平扩展能力；
• 提供类似关系型数据库的事务能力；
• 适合更大规模的分布式数据存储；
• 尝试统一扩展性、一致性与事务处理。

局限

• 架构和实现更加复杂；
• 分布式事务和强一致性会增加通信成本；
• 在高并发和事务处理方面仍需要根据具体产品验证；
• 本节认为，短期内难以完全取代关系型数据库和传统 NoSQL。

七、数据库类型对比

八、选型思路

数据库选型应该从业务访问模式出发，而不是只看产品热度。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

字段是否经常变化？
  └─ 是 → 考虑文档数据库

是否为海量写入和少数列统计？
  └─ 是 → 考虑列式数据库

是否需要关键词搜索？
  └─ 是 → 考虑全文搜索数据库

是否需要复杂关系和多跳查询？
  └─ 是 → 考虑图数据库

是否同时需要事务、强一致和水平扩展？
  └─ 是 → 评估 NewSQL

在大型系统中，通常不是只选择一种数据库，而是采用多种存储系统组合使用：

1
2
3
4
5

MySQL：核心事务数据
文档数据库：动态结构数据
列式数据库：海量分析数据
Elasticsearch：搜索索引
图数据库：复杂关系

每种数据库只处理它最擅长的问题。

九、核心架构思想

1. 不存在适合所有业务的数据存储系统。
2. 文档数据库使用灵活 Schema，适合字段不统一、变化频繁的数据。
3. 列式数据库只读取相关列，适合海量数据分析和离线统计。
4. 同列数据类型相近且重复率高，因此列式存储更容易进行压缩。
5. 全文搜索数据库通过倒排索引建立关键词到文档的映射。
6. 图数据库将节点和关系作为核心结构，适合复杂关系查询。
7. NoSQL 往往通过弱化事务和强一致性，换取灵活性、性能或扩展能力。
8. NewSQL 试图结合 NoSQL 的扩展能力与关系型数据库的事务能力。
9. NewSQL 通常依赖 LSM Tree、数据分片、分布式共识和分布式事务。
10. 实际架构应根据数据结构、读写模式、一致性和查询需求进行组合选型。

十、一句话总结

不同 NoSQL 数据库分别针对特定问题进行优化：文档数据库强调灵活 Schema，列式数据库强调海量写入与分析，全文搜索数据库依靠倒排索引实现高效检索，图数据库擅长复杂关系查询；NewSQL 则进一步尝试将 NoSQL 的水平扩展能力与关系型数据库的强一致和事务能力结合起来。