NoSQL

定义

NoSQL 指一类不以关系表结构为核心的数据管理系统，与以 SQL 为通用查询语言的关系型数据库相对^[4]。它涵盖的不是单一产品或单一技术，而是包含多种数据模型的一族系统，通常还包括无固定模式、面向集群部署等共同倾向^[5][1]。

在中文语境中，NoSQL 通称「非关系型数据库」；腾讯云技术百科将其界定为面向大规模、高并发、分布式数据存储与访问的数据库类别。这一概念没有正式标准组织或统一宣言，边界较为模糊，因此不同资料列举的成员并不完全一致^[6]。

按数据模型划分，常见类型有键值存储、文档存储、宽列（列族）存储和图数据库四类，近年还出现了同时支持多种模型的多模型数据库^[2][7]。

原理

键值存储以唯一的键与对应的值构成基本单元，写入与读取都通过键定位，结构最简单，Redis、Amazon DynamoDB 属于此类，常用于缓存与会话管理^[7][2]。文档存储把数据组织成 JSON 或 BSON 文档，同一集合内的文档字段可以不同，并支持嵌套结构，MongoDB、CouchDB 属于此类^[7]。

宽列存储按列族组织数据，每行由唯一的行键标识，不同行可拥有不同的列集合，并可利用列压缩减少存储占用，Apache Cassandra 与 HBase 是代表产品^[7][8]。图数据库以节点和边表达实体及其联系，适合对关系做深度遍历，Neo4j 是常见实现^[7]。

多数 NoSQL 系统的设计建立在 CAP 定理之上。该定理由埃里克·布鲁尔(Eric Brewer)于 2000 年提出，认为分布式系统在一致性、可用性和分区容错性三者中最多同时满足两项；不少 NoSQL 系统优先保障可用性与分区容错，转而提供最终一致性^[4]。与之相应的 BASE 模型强调基本可用、软状态与最终一致，与关系型数据库的 ACID 模型形成区别^[3]。

在服务端，副本数 $N$、写操作需确认的节点数 $W$ 与读操作需访问的节点数 $R$ 之间存在权衡：当 $W+R>N$ 时读写集合必然重叠，可得到强一致；当 $W+R\le N$ 时则可能出现读到旧值的情况^[9]。部分产品还提供可调节的一致性级别，允许按操作在延迟与一致性之间取舍^[4]。

flowchart LR

A[应用请求] --> B{选择的 NoSQL 类型}

B --> C[键值: 按键读写]

B --> D[文档: JSON/BSON 文档]

B --> E[宽列: 行键+列族]

B --> F[图: 节点与边遍历]

C --> G[多节点分布式存储]

D --> G

E --> G

F --> G

G --> H[副本复制与分片]

H --> I[按 CAP 取舍一致性]

发展历程

「NoSQL」一词最早出现于 1998 年，是卡洛·斯特罗齐(Carlo Strozzi)为其开发的一个轻量、开源、不提供 SQL 接口的关系型数据库所起的名字，与今天所指的数据库类别并无直接承继关系^[1][10]。

2009 年，Last.fm 的约翰·奥斯卡松(Johan Oskarsson)发起关于分布式开源数据库的讨论，来自 Rackspace 的埃里克·埃文斯(Eric Evans)在这一场合重新使用了 NoSQL 一词，用以指称非关系型、分布式、通常不提供 ACID 保证的数据存储^[1][10]。同年在美国亚特兰大举行的 no:sql(east) 会议被视为这一运动的标志性事件，其口号带有对关系模型的调侃意味，此后对 NoSQL 最常见的解释落到「非关系型」上^[1]。

技术源头方面，谷歌于 2006 年发表 Bigtable 论文、亚马逊于 2007 年发表 Dynamo 论文，描述了两家公司内部使用的分布式存储系统，随后开源社区据此构建出 Cassandra、HBase、MongoDB、Redis 等被广泛部署的产品^[4]。2009 年前后 MongoDB 与 CouchDB 等文档数据库集中出现，2010 年代各类 NoSQL 产品逐渐被企业普遍接受^[2]。

推动这一转变的背景是存储成本大幅下降，以及网络应用需要处理传统关系型数据库难以承载的数据规模与访问并发；同时敏捷开发与云计算的普及，也要求数据层能更快适应需求变化^[2]。

应用

NoSQL 系统主要用于数据量大、访问并发高或结构不固定的场景。键值存储适合缓存、会话管理和用户资料查询；文档存储适合内容管理、商品目录与电商平台；宽列存储适合日志、时序指标与遥测数据管道；图数据库适合社交关系、推荐网络和知识图谱这类关系密集的查询^[4][7]。

大数据分析与实时事件流处理是常见用途，包括对日志数据的批处理与实时聚合、面向可变属性商品的分析型工作负载，以及需要高写入吞吐的物联网传感器数据采集^[4]。社交平台用这类系统保存用户关系图与动态信息流，推荐引擎则用图结构遍历用户与物品之间的交互网络^[4]。

实践中常把多种存储组合使用，让关系型数据库承担核心交易，NoSQL 承担缓存与辅助存储，这种按用途分别选型的做法被称为多语言持久化^[11][5]。

局限

NoSQL 系统通常不提供与传统关系型数据库同等的事务保证，跨行、跨文档、跨键的多记录事务往往缺失，开发者需要在应用层处理一致性。许多产品采用最终一致性，在高并发或网络分区时可能出现读到过期数据的情况，因此不适合对账务准确性要求严格的核心交易场景^[3][12]。

由于各家产品自行定义查询与响应格式，缺少统一标准，跨产品迁移的成本较高，SQL 那样的通用查询能力也相应弱化^[3]。部分资料还指出，这类系统在原生安全功能方面不如成熟的关系型产品完备^[8]。

在部署形态上，部分 NoSQL 产品依赖由多台机器组成的集群并行处理数据，若运行在单节点上，性能未必优于常见关系型数据库；对于结构固定、规模仅数 GB 至数 TB 的数据，这类系统通常不是合适选择^[13]。微软的课程材料同时指出，NoSQL 数据库并非适用所有问题，应按具体任务选择合适的工具^[13]。

参见

• 关系型数据库 —— NoSQL 所对照的传统数据库类别，以表和 SQL 查询为核心。

• CAP定理 —— 分析分布式数据系统一致性、可用性与分区容错取舍的理论基础。

• 最终一致性 —— 多数 NoSQL 系统采用的一致性模型。

• MongoDB —— 典型的文档型 NoSQL 数据库。

• Redis —— 典型的键值型 NoSQL 数据库。

• 图数据库 —— 以节点和边建模的 NoSQL 分支。