SQL 与 NoSQL：在数据库决定你的命运之前，选择正确的数据库

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

SQL 还是 NoSQL——这场争论不仅仅关乎数据库，更关乎你的应用程序将如何思考、发展和扩展。

选错了，你最终可能不是在开发产品，而是在和数据库作斗争。

如果今天你选择的数据库导致你的应用程序运行缓慢、无法扩展，或者以后需要花费数千美元来修复，那该怎么办？

让我们确保这种情况永远不会发生。

在设计数据驱动型应用程序时，选择 SQL 还是 NoSQL 是您需要做出的最重要的决定之一。

两者各有优势、劣势和理想的使用场景，选择会影响系统的性能、可扩展性，甚至开发速度。

在本指南中，我们将详细介绍 SQL 和 NoSQL 的概念、各自的优势、优缺点，以及如何选择适合您的方案。

什么是SQL？

• SQL（结构化查询语言）是一种标准化的、特定领域的编程语言，用于访问、操作和管理关系数据库管理系统（RDBMS）中的数据。

• 数据以表格形式组织，表格包含行和列，并强制执行严格的模式。SQL 操作示例包括 `SELECT` SELECT、INSERT`SELECT`、UPDATE`SELECT`、DELETE`SELECT` 以及涉及 `SELECT` 的高级查询JOINs。

什么是NoSQL？

• NoSQL（“不仅仅是 SQL”）指的是一大类非关系型数据库，它们以不同于传统基于表的数据库的方式存储和检索数据。

• NoSQL数据库有多种类型：键值数据库、文档型数据库、宽列数据库和图数据库。它们支持灵活的模式，并专为高可扩展性、高性能以及处理非结构化或半结构化数据而设计。

SQL 和 NoSQL 数据库的用途

SQL

• 适用于需要一致、结构化数据的应用：财务系统、ERP、CRM、电子商务以及任何对 ACID 事务和复杂查询要求极高的领域。

• 常见于分析工作负载、数据仓库和事务处理系统中。

NoSQL

• 适用于需要灵活性和可扩展性的场合：大数据分析、社交网络、内容管理、物联网和移动应用程序。

• 非常适合处理快速演变的数据模型、存储大量非结构化数据以及支持跨多个服务器的水平扩展。

何时应该使用 SQL，何时应该使用 NoSQL？

SQL 最适用于以下情况：

• 您的数据结构良好，非常适合用表格形式呈现（表格模型）。

• 你需要强大的数据一致性（例如，财务交易）。

• 您的应用程序需要复杂的查询和连接操作。

在以下情况下，NoSQL 更可取：

• 数据是非结构化、半结构化或频繁变化的。

• 可扩展性和分布式架构非常重要（例如，Web 规模应用程序、物联网、流数据）。

• 您需要高读写吞吐量、灵活的模式，或者必须以最小的开销存储大型数据集。

流行的 SQL 和 NoSQL 数据库

优点和缺点

SQL数据库

优点：

• 强数据一致性（ACID特性）。

• 强大的查询功能，包括 JOIN 和聚合。

• 成熟的生态系统，在企业环境中得到良好支持。

• 标准化的语言和强大的交易支持。

缺点：

• 结构僵化；结构变化复杂。

• 垂直扩展（受硬件升级限制）。

• 处理大量数据时可能会消耗大量资源。

• 不太适合处理非结构化或半结构化数据。

NoSQL数据库

优点：

• 通过跨服务器的水平分布实现高度可扩展性。

• 灵活的模式；动态的数据模型。

• 在高负载或大数据量下性能良好。

• 适用于快速发展和不断变化的需求。

缺点：

• 可能为了性能而牺牲高度一致性（最终一致性）。

• 对复杂查询和连接的支持有限。

• 多样化的模型（键值、文档、图表等）——学习曲线可能
  更陡峭。

• ACID的保证可能缺失或有限。

现在让我们深入探讨一下优缺点。

酸的性质有哪些？

ACID 是一组保证，它包含四个要素，确保数据库中的事务可靠：

SQL 数据库如何支持 ACID

像 MySQL、PostgreSQL、Oracle、SQL Server 这样的传统关系型数据库都是围绕 ACID 原则设计的。

他们是如何做到的：

• 原子性 → 事务可以启动，如果出现任何故障，BEGIN也可以回滚。ROLLBACK

• 一致性 → 通过以下方式强制执行：

  • 数据类型
  • 约束条件（PRIMARY KEY，，FOREIGN KEY）CHECK
  • 触发器和规则

• 隔离 → 通过锁定和隔离级别（READ COMMITTED，，SERIALIZABLE等）实现。

• 耐久性 → 通过以下方式实现：

  • 预写式日志（WAL）——更改在应用之前会被记录下来。
  • 数据复制和备份。

例子：

BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
COMMIT;

如果任何更新失败，SQL 会确保整个操作回滚。

GIF

为什么许多 NoSQL 数据库不完全支持 ACID

许多 NoSQL 数据库（例如 MongoDB、Cassandra、Couchbase）优先考虑可扩展性和可用性，而不是严格的 ACID——尤其是在分布于多个服务器上时。

挑战：

• 分布式特性 → 在多个节点上保持强 ACID 特性成本高昂且速度缓慢。

• 相反，许多人遵循 BASE：

  • 基本可用 → 系统始终响应迅速。
  • 软状态 → 数据可能会随时间发生变化（最终一致性）。
  • 最终一致性 → 所有副本最终都会达成一致，但不会立即达成一致。

• 许多 NoSQL 系统为了获得以下优势而放宽了隔离性和一致性要求：

  • 更快的写入速度
  • 更易于水平缩放
  • 网络故障时的高可用性

❗重要提示

• 并非所有 NoSQL 都是非 ACID 的，有些 NoSQL 提供部分或可选的 ACID 支持。

  • MongoDB → ACID 事务支持多文档操作（自 v4.0 起），但性能有所妥协。
  • Cassandra → 轻量级事务，隔离程度有限。

• 但默认情况下，大多数 NoSQL 系统为了性能和可扩展性而倾向于使用 BASE 数据库。

SQL数据库不太适合处理非结构化或半结构化数据。

SQL 数据库不太适合处理非结构化或半结构化数据，这主要是因为它们的核心设计方式。

1. SQL 数据库期望采用固定模式

• 在 SQL 中，必须先定义模式（表、列、数据类型）才能插入数据。

• 表中的每一行都必须遵循此模式。

• 非结构化数据的问题：

  • 非结构化数据（例如图像、视频、自由文本）和半结构化数据（例如 JSON、XML）无法整齐地放入固定的表格中。
  • 如果数据结构经常变化，则需要反复修改架构，这既昂贵又会造成干扰。

2. 数据与行和列的匹配度很差

• SQL数据库是面向行和面向列的。

• 非结构化数据通常具有：

  • 每条记录包含不同的字段。
  • 可选属性或嵌套属性。

• 尝试将此数据存储在 SQL 中意味着：

  • 许多NULL未使用的列都有值。
  • 用于表示嵌套关系的复杂连接表。
  • 性能下降。

3. 嵌套或可变数据的复杂存储

• 半结构化数据（例如 JSON）可以存储在现代 SQL 数据库（例如 PostgreSQL 的 jsonb）中，但是：

  • 它失去了关系表的许多查询优化优势。
  • 对 JSON 字段进行索引和搜索速度较慢，且更消耗资源。

• NoSQL 文档数据库（如 MongoDB）能够原生处理嵌套的可变字段，因此在此类用例中速度更快。

4. 规模和灵活性问题

• 非结构化/半结构化数据的增长方式难以预测。

• SQL严格的模式和垂直扩展方式使其更难适应。

• NoSQL 的灵活模式和横向扩展能力更适合处理不断变化且规模庞大的非结构化数据集。

NoSQL 数据库支持灵活的模式

我们所说的 NoSQL 数据库支持灵活的模式，是指：

1. 无预定义表结构

• 在 SQL 中，必须先定义所有列及其类型才能插入数据。

• 在 NoSQL（例如 MongoDB、Cassandra、DynamoDB）中，您不必预先定义所有字段。

• 您可以在同一集合/表中插入一条具有特定字段的记录和另一条具有完全不同字段的记录。

2. 不同的记录可以有不同的结构

MongoDB（文档数据库）示例：

// Document 1
{
  "name": "Vignesh",
  "email": "vignesh@example.com"
}

// Document 2
{
  "name": "Raj",
  "phone": "9876543210",
  "address": {
    "city": "Chennai",
    "zip": "600001"
  }
}

这里：

• Vignesh有一个email字段，但没有phone。

• Raj有phone嵌套address但没有email。

• 两者都存储在同一个集合中，无需更改架构。

3. 易于进化

• 您可以随时添加、删除或重命名字段，而无需更改整个数据库结构。

• 这在以下情况下尤其有用：

  • 您的数据模型经常发生变化。
  • 您正在存储非结构化或半结构化数据（例如，JSON、XML）。
  • 您需要处理格式各异的各种数据源。

4. 读取时模式与写入时模式

• SQL 使用写时模式 → 插入数据时强制执行结构。

• NoSQL 通常采用读取时模式 → 在检索/处理数据时应用结构。

• 这意味着您可以存储原始的、不规则的数据，并在以后对其进行处理。

什么是垂直扩展（向上扩展）？

• 含义：增加单台机器（服务器）的处理能力，使其能够处理更多负载。

• 具体做法：给同一台服务器增加 CPU、内存、存储空间或更快的磁盘。

• 打个比方：就像买一台更大、更快的笔记本电脑，而不是拥有多台笔记本电脑一样。

SQL数据库和垂直扩展

• 传统的 SQL 数据库（如 MySQL、PostgreSQL、Oracle）以结构化的关系格式存储数据。

• 为了保证一致性并处理复杂查询，它们通常被设计成在一台功能强大的机器上运行。

• SQL 横向扩展（跨多个服务器）更难，因为：

  • 他们非常依赖交易（ACID 合规性）。
  • 数据通常是相互关联的（跨多个表连接）。
  • 在保持数据关系的同时进行数据分割（分片）是一项复杂的工作。

• 因此，更简单的方法是：

增强单台机器的性能 → 垂直扩展。

什么是水平缩放（横向扩展）？

• 含义：增加更多机器（服务器）来分散负载。

• 实现方式：使用多台服务器分担工作负载，数据通常分布在多台服务器上。

• 类比：与其购买一台超级计算机，不如购买 10 台普通计算机，让它们协同工作。

NoSQL数据库和水平扩展

• NoSQL 数据库（如 MongoDB、Cassandra、Couchbase）以非关系型的方式存储数据（文档、键值对、宽列等）。

• 它们从一开始就以分销为设计目标：

  • 数据可以轻松地分片到多个服务器上。
  • 每个服务器处理一部分数据。
  • 这样只需增加机器数量即可处理海量数据集和高流量。

• 因此，常用的缩放方法是：

添加更多服务器来分担工作 → 横向扩展。

结论

在SQL和NoSQL之间进行选择，并非是要比较哪一个更好，而是要看哪一个更符合你的数据模型、增长计划和应用程序需求。

把它想象成盖房子：你不会为摩天大楼选择和为小木屋选择相同的地基。

• 如果您需要结构化、一致性和可靠性，SQL 数据库可提供久经考验的稳定性。

• 如果您需要灵活性、规模化速度和不断发展的数据模型，NoSQL 可以为您提供所需的敏捷性。

最成功的项目始于清晰的思路，而不是猜测。

今天选择合适的数据库，不仅可以避免代价高昂的错误，还能让你的应用程序在未来几年内优雅地扩展。

在领英| GitHub |推特上关注我

订阅我的电子报，即可直接在您的邮箱中收到文章。

开发者技术栈 | Vignesh J | Substack

订阅“技术快讯”和企业职场内幕故事，掌握最新资讯，直接发送至您的邮箱。点击阅读 Vignesh J 撰写的 Substack 出版物《开发者技术栈》。该文章于 33 分钟前发布。

thedeveloperstack.substack.com