Day28-19｜6.5.1 NoSQL 数据库的分类与特点
Day28-19｜6.5.1 NoSQL 数据库的分类与特点：按数据特征选择模型，而不是追逐产品标签
本文对应《系统架构设计师教程（第2版）》第6章“数据库设计基础知识”6.5.1“NoSQL 数据库的分类与特点”。NoSQL 通常指一组不完全遵循传统关系数据库组织方式的数据管理技术，常见类型包括键值数据库、文档数据库、列族数据库和图数据库。它们主要为海量数据、高并发、灵活结构、水平扩展、低延迟或复杂关系遍历等场景提供不同能力。系统架构师需要理解 NoSQL 解决的问题、牺牲的能力和治理要求，避免把“NoSQL”误解为“不需要设计数据库”。
一、学习目标与考试定位
完成本节后，应能够说明 NoSQL 的产生背景和共同特点；掌握键值、文档、列族、图数据库的结构、访问方式、优点、局限和典型场景；理解模式灵活性、聚合、分片、复制、一致性和可用性之间的关系；能够根据业务访问模式选择 NoSQL 类型；能够分析 NoSQL 中的热点、数据倾斜、重复、最终一致性、事务边界和数据治理问题；能够在案例题和论文中说明关系数据库与 NoSQL 的协同架构。
考试不会只要求背四类数据库名称，更常给出业务场景：购物车按用户快速读取，商品属性经常变化，海量日志按时间写入，社交关系需要多跳遍历。答题要指出数据模型、主访问路径、数据规模、读写比例、一致性和故障目标，再说明为什么选择某类 NoSQL，以及如何解决其代价。
二、NoSQL 的产生背景
传统关系数据库在事务、一致性、复杂查询、约束和管理方面非常成熟，但互联网和云环境带来了一些新的压力：数据量和访问量快速增长；数据结构多样且变化频繁；服务需要按业务拆分和独立扩展；用户分布广、要求低延迟；日志、事件、文本和关系数据规模巨大；部分场景可以接受短暂不一致。
NoSQL 通过简化数据模型、面向访问模式组织数据、水平扩展、分布式复制和灵活模式，换取特定场景下的吞吐、延迟或开发效率。它不是对关系数据库的全面替代，而是数据架构中的一种工具。
NoSQL 的共同特点通常包括：弱化或不强制固定模式；支持水平扩展；通过分片和复制提高容量与可用性；针对特定访问模式优化；部分系统提供有限事务或最终一致性；把更多数据约束、关联和聚合责任交给应用或服务。
三、键值数据库
键值数据库以唯一键映射一个值，值可以是字符串、对象、列表、集合或二进制数据。访问方式主要是按键读取、写入、删除和设置过期时间。
1. 优点
模型简单，按键访问延迟低，容易水平扩展；适合缓存、会话、购物车、分布式锁、配置、计数器和幂等记录。很多键值系统支持 TTL、原子操作、集合和发布订阅等能力。
2. 局限
复杂条件查询、关联、范围分析和跨键事务通常能力有限；如果把业务数据全部塞成一个值，局部更新和一致性会变得困难。键的设计决定路由、热点、生命周期和可观察性，不能使用含义不稳定或过长的键。
3. 设计重点
明确键命名空间、租户隔离、过期策略、最大值大小、缓存击穿、穿透、雪崩和重建；对关键业务状态要明确权威数据库，键值库不能在缓存失效后成为唯一事实源，除非系统专门设计了持久性、备份和恢复。
四、文档数据库
文档数据库以 JSON、BSON 或类似文档作为基本单元，允许嵌套对象和数组，字段结构可以随文档变化。文档通常围绕业务聚合组织，使一次读取能够获得完整展示或操作所需的信息。
1. 适用场景
商品详情、内容、用户偏好、配置、订单展示快照和事件数据等，适合按聚合整体读取、结构变化较快或关联层级有限的场景。
2. 嵌入与引用
嵌入可以减少连接和网络往返，适合从属、一起读取且大小可控的数据；引用适合独立生命周期、共享、频繁更新或规模不断增长的数据。嵌入过多会导致文档过大、并发冲突和局部更新成本；引用过多则会失去文档模型的读取优势。
3. 一致性和索引
需要明确文档内部原子更新范围、跨文档事务、唯一性、版本和并发。文档数据库仍然需要索引、模式校验、字段治理和数据生命周期，灵活模式不等于无模式。
五、列族数据库
列族数据库按照行键、列族和列组织数据，常针对海量稀疏数据和分布式写入进行设计。不同记录可以拥有不同列，数据通常按访问路径和分区键组织，适合按键和范围扫描。
1. 典型场景
时间序列、日志、设备测量、消息记录、用户行为和大规模宽表等。常见访问模式是按设备或用户、时间范围读取或写入大量记录。
2. 设计重点
分区键决定数据分布和热点，聚簇或排序键决定分区内范围读取。时间单调增长可能使最新分区成为热点；分区过大影响读写和修复，过小则产生大量分区管理开销。查询通常要围绕事先设计的访问模式，不能期待关系数据库式任意连接。
3. 一致性与维护
复制和修复会产生延迟，删除可能使用墓碑记录，压缩和合并会消耗资源。应设置 TTL、分区大小、修复、备份、监控和数据重建策略。
六、图数据库
图数据库以节点、边和属性表达实体与关系，关系是第一等公民。它适合社交网络、知识图谱、推荐、反欺诈、路径规划、依赖关系和网络拓扑等多跳遍历场景。
图模型的优势是关系遍历和路径查询表达自然，新增关系类型较灵活；局限是通用事务、分布式扩展、批量分析、分片和治理可能更复杂。只有当多跳关系查询是核心访问模式时，图数据库的收益才足以抵消额外复杂度。
图数据也需要节点和边的标识、唯一性、生命周期、权限和版本。关系的方向、类型和有效期要明确，避免把所有事实都建成无约束的边。
七、NoSQL 中的模式设计
NoSQL 常说“模式灵活”，实际设计仍然要先根据访问模式确定数据结构。关系数据库通常先规范化再根据查询优化，NoSQL 往往先识别查询、聚合和分区，再设计嵌入、冗余和索引。
一个典型设计流程是：列出主要读写场景；估计数据量、并发和增长；确定聚合边界和主键；选择分片或分区键；决定嵌入和引用；设计索引、TTL、版本和一致性；验证热点、故障、备份和重建。
冗余是 NoSQL 常见手段，用于减少连接和提升读取性能，但必须记录权威来源、同步方式、失败补偿、对账和重建。没有治理的冗余会产生多个互相矛盾的“真相”。
八、一致性、可用性与 CAP
分布式 NoSQL 通常通过复制和多节点提供高可用和扩展，但网络分区、节点故障和复制延迟会带来一致性选择。在发生网络分区时，系统通常需要在一致性和可用性之间做取舍。CAP 不是简单地说系统平时只能拥有两个特性，也不是选择 NoSQL 就必然最终一致；应结合具体故障模型、数据类型和业务容忍度分析。
强一致适合余额、库存、权限和关键状态；最终一致适合缓存、推荐、计数、搜索索引和部分统计。最终一致不是“不一致”，而是要定义收敛、延迟、冲突、重试、补偿和用户可见行为。
九、事务和跨数据操作
部分 NoSQL 提供单文档原子性、分区内事务或有限多文档事务，但跨分片和跨服务事务通常成本较高。设计时要把强一致操作收敛到合适的聚合和分区内，跨聚合流程使用事件、状态机、幂等、补偿和对账。
应用不能因为数据库没有外键就忽略完整性。可以通过唯一键、版本号、条件更新、状态转换、消息顺序和定期对账维护关键不变量。对账和重建是 NoSQL 数据架构的重要能力。
十、扩展、热点与数据倾斜
水平扩展的关键是分片键。理想分片键应稳定、分布均衡、常用于路由、具有足够基数且不易变化。按时间、热门用户或热门商品分片可能产生热点；按哈希可以均衡，但范围查询和归档较复杂。
热点处理可以采用复合分片键、哈希前缀、热点拆分、缓存、限流、异步写入和读副本。数据倾斜会导致某些节点容量、CPU、网络或修复压力显著高于其他节点，必须监控分片分布和单键访问量。
扩容要考虑数据重分布、双写、路由更新、迁移限速、读写一致性和回滚。扩容不是把节点数量加一就完成，必须验证业务延迟、数据完整性和故障恢复。
十一、安全、治理和运维
NoSQL 仍需身份认证、最小权限、网络隔离、传输和存储加密、审计、备份、恢复和漏洞管理。灵活文档中的敏感字段要分类分级，不能因没有固定表结构就绕过治理。
运维要监控节点健康、分片、复制延迟、热点、查询延迟、写入失败、存储、压缩、修复、TTL、缓存命中和数据质量。备份恢复要覆盖数据、索引、模式校验、权限和应用配置，并进行实际恢复演练。
十二、关系数据库与 NoSQL 的协同
成熟系统常采用多存储架构：关系数据库保存核心事务和权威事实，键值库保存缓存和会话，文档库保存聚合读模型，列族库保存海量时间序列，图数据库保存关系网络，搜索或分析系统服务特定查询。
多存储架构的关键是明确数据流和权威来源。通过事件或 CDC 同步时，要处理重复、乱序、延迟、失败、重放和删除；读模型可重建，不能只依赖不可追溯的增量结果；跨存储对账、监控和权限要统一。
十三、案例分析：设备平台的列族数据库热点
某物联网平台使用列族数据库保存设备数据，分区键为“设备类型+日期”。某型号设备数量远大于其他型号，且所有设备的当天数据集中写入少数分区，导致节点热点和写入超时。团队尝试增加副本，但热点仍然存在；查询最近一天数据时又需要扫描大量分区。
问题分析
分区键基数和分布不均，设备类型无法充分分散数据；日期使当前窗口集中写入；增加副本主要改善读取或容灾，不能解决主写入热点；查询模式没有与分区和排序键协同设计。
改进方案
采用设备标识或哈希桶加时间窗口作为复合分区键，把同一型号的数据分散到多个桶；使用设备标识和时间作为分区内排序维度，支持按设备和时间范围读取；通过路由层并行查询和受控合并满足跨桶查询；对热数据和历史数据分层。扩容前进行数据重分布、迁移限速和双读校验，监控单分区写入、延迟、存储和复制，并设计热点设备的限流和降级。
十四、综合知识练习与详细答案
练习一
购物车按用户编号读写，为什么键值数据库通常合适？需要注意哪些问题？
参考答案：购物车主要按唯一用户键快速读取和更新，结构相对聚合，键值访问延迟低且易扩展。需要设置过期和容量，处理并发更新、幂等、缓存丢失、持久化、备份和恢复；若购物车是交易唯一事实，还要明确权威来源，不能只依赖易失缓存。
练习二
商品属性经常增加，为什么文档数据库可能比固定表更灵活？其风险是什么？
参考答案：文档可以嵌套和按商品类型保存不同字段，模式演进不必频繁改表，适合按商品聚合读取。风险包括字段口径不一致、文档过大、索引治理、局部更新冲突、跨文档关联和数据质量下降；应采用版本、校验规则、索引白名单、聚合边界和迁移治理。
练习三
推荐关系需要查询“朋友的朋友”多层路径，为什么图数据库可能合适？什么时候不适合？
参考答案：图数据库把节点和边作为一等数据，路径和多跳遍历表达自然，适合关系查询是核心的场景。不适合关系只有一两层、主要是事务更新或需要大规模报表聚合的场景；此时关系数据库、搜索或专用分析结构可能更简单。仍需评估规模、分布式扩展、事务、权限和运维能力。
十五、论文写作素材
论文中可以这样描述 NoSQL 选型：面对海量、灵活和高并发数据，我先分析访问模式、数据聚合、容量增长、读写比例、一致性、可用性、延迟和团队能力，再选择键值、文档、列族或图模型，而不是按技术潮流统一替换关系数据库。核心订单、库存和支付事实保留适合事务和约束的权威存储，缓存、内容、时间序列和关系遍历使用匹配的 NoSQL 能力。
在设计 NoSQL 模型时，我明确主键、聚合、分区键、排序键、嵌入与引用、索引、TTL、版本、复制和一致性策略；对冗余字段记录权威来源、事件、延迟、失败补偿、对账和重建。针对热点和数据倾斜使用复合键、哈希桶、限流、路由和在线迁移，验证扩容、重分布和故障切换。
多存储协同时通过消息或 CDC 解耦交易与查询，处理重复、乱序、延迟、删除和重放；建立数据质量、权限、审计、备份恢复和成本监控。最终以业务指标、P95/P99 延迟、吞吐、数据一致性和恢复目标验证方案，使 NoSQL 成为可治理的架构组成而不是不可追溯的数据孤岛。
十六、今日复盘
NoSQL 的核心不是“没有 SQL”，而是面向特定规模、访问模式和分布式约束选择数据模型。键值适合按键低延迟，文档适合聚合和灵活结构，列族适合海量稀疏和时间序列，图适合多跳关系。NoSQL 常用水平扩展、复制和冗余，但必须承担一致性、热点、数据治理、事务、对账、备份和重建责任。
记忆主线：
先看访问模式，再选数据模型；先定权威事实，再做冗余投影；先做容量和故障验证，再谈扩展和可用性。
下一篇进入 6.5.2 NoSQL 数据库体系框架，学习 NoSQL 的数据层、分布式存储、计算、接口、治理和运维框架。
