关系型数据库的局限性

关系型数据库以 SQL 为驱动，几十年来一直是数据管理的核心工具。它们提供了一种可靠、结构化的方式来存储和查询信息，通过诸如表、主键和 ACID 特性（原子性、一致性、隔离性、持久性）等来确保数据的一致性和完整性。对于许多应用，特别是那些处理定义明确的结构化数据，如客户记录、财务交易或库存管理的应用，关系型模型仍然是出色的选择。

然而，随着应用及其生成的数据不断发展，传统关系型方法面临挑战的情况也随之出现。弄清这些局限性有助于说明为什么替代的数据库模型（通常归为 NoSQL）会应运而生。接下来，我们来分析一些关系型数据库可能不那么适合的情形。

扩展性面临的挑战

一个主要挑战与扩展性有关，即数据库处理不断增长的数据量以及日益增多的用户或请求的能力。

• 垂直扩展（向上扩展）： 传统上，关系型数据库采用垂直扩展。这意味着如果你需要更强的处理能力，可以升级现有服务器：增加 CPU、内存或更快的存储设备。虽然这种方式在一定程度上有效，但单台机器的升级存在物理限制，且高端硬件可能非常昂贵。
• 水平扩展（向外扩展）： 另一种选择是水平扩展，即将数据库负载分散到多台（通常成本较低的）普通服务器上。虽然关系型数据库可以进行水平扩展，但这通常会带来相当大的复杂性。在多台机器上维护严格的一致性（ACID 中的“C”），特别是对于写入操作，可能很困难，并可能影响性能。像复杂连接这种需要来自不同机器数据的操作也可能变得缓慢且难以管理。

对于需要大规模扩展的应用，例如同时处理数百万用户数据或处理海量入站信息流的应用，传统关系型数据库在水平扩展方面的固有困难，促使人们寻求新的解决方案。

模式要求严格

关系型数据库强制执行预定义的模式。在存储任何数据之前，你必须定义其结构：表、表中各列、每列的数据类型（例如，整数、文本、日期）以及表之间的关系。

这种结构是一个优势，因为它强制了一致性并使数据可预测。然而，它也可能是一个局限：

• 开发灵活性： 在快节奏的开发环境，特别是在早期阶段或采用敏捷方法时，确切的数据结构可能频繁变化。修改关系型数据库中的模式（例如，添加列、更改数据类型）可能是一个复杂且可能具有破坏性的操作，尤其当数据库已包含大量数据时。
• 数据变化： 有时数据本身没有固定结构或随时间演变。设想存储用户资料，其中不同用户可能有非常不同的属性；或者产品目录不断添加新功能。将所有变体强制纳入严格的表结构可能变得不便，可能导致大多数行中许多列为空 (NULL)，或者需要复杂的表设计。

处理非结构化或半结构化数据的难度

关系型模型擅长处理结构化数据：能够整齐地适配行和列的信息，例如姓名、地址、订单日期和数量。然而，当今生成的大部分数据是非结构化的（如电子邮件或文档中的自由格式文本、图像、音频、视频）或半结构化的（如 JSON 或 XML 文档，它们具有一些内部组织，但不是严格的表状格式）。

尽管关系型数据库可以存储这类数据（通常使用大型文本字段如 TEXT 或二进制字段如 BLOB - Binary Large Object），但它们通常不提供使用标准 SQL 直接高效查询数据内容的方法。例如，查找存储在 TEXT 字段中提及特定项目的所有电子邮件，需要更复杂的索引或应用层处理，而不是简单的 SQL 查询。关系型数据库并非从根本上为这类数据设计的。

特定工作负载下的性能考量

尽管关系型数据库经过高度优化，但某些操作仍可能成为性能瓶颈，特别是在大规模情况下：

• 复杂连接： 需要连接多个大型表数据的查询，可能计算开销大并拖慢响应速度。
• 高吞吐量 (throughput)写入： 需要极快写入数据的应用（例如，日志系统、传感器数据收集器、实时分析）可能会发现，关系型数据库中为每个写入操作维护严格 ACID 保证所需的开销会限制吞吐量。

这些局限性不代表关系型数据库有缺陷。它们是适用于许多任务的强大工具。然而，认识到这些挑战有助于我们理解开发 NoSQL 数据库的动机，NoSQL 数据库通常会牺牲关系型模型的一些保证（例如固定模式或所有节点间的即时一致性），以在扩展性、灵活性和针对特定数据类型和应用工作负载的性能方面获得优势。下面的内容将向您呈现这些替代方案。