如果您正计划启动一个新的数字化应用，您很可能需要收集并存储一些数据。在哪里以及如何存储这些数据，是您必须做出的最重要决定之一，因为整个软件的运行都依赖这些数据。
传统上，数据以表格的形式存储，表中包含行和列，并通过某些关系（例如公共列）相互连接。存储关系型数据的数据库称为关系型数据库，或 SQL 数据库，因为大多数（如果不是全部）操作都依赖 SQL 来完成。
然而，近几十年来，为了应对每秒产生的数据量与多样性的快速增长，新的数据库管理系统不断发展。所谓的 NoSQL 数据库（Not only SQL）基于特定用例提出了新的模式与策略，以更有效地收集数据，同时在一定程度上仍依赖 SQL。
在本文中，我们将分析两种流行的数据库管理系统：PostgreSQL 与 MongoDB。前者是最受欢迎的 SQL 数据库之一，后者则是最著名的 NoSQL 数据库。
我们将介绍两种数据库的关键特性与优势、最具代表性的使用场景，以及在考虑将数据迁移到其中任一数据库时需要注意的要点。
如果您希望动手实践并尝试每种方法，务必查看我们的课程 Creating PostgreSQL Databases 和 Introduction to MongoDB in Python。
要点速览：PostgreSQL vs MongoDB
为任何数字化应用选择合适的数据库至关重要。PostgreSQL 作为基于 SQL 的强大关系型数据库，在需要一致性、复杂连接与 ACID 事务的结构化数据场景中表现出色。MongoDB 是一种使用 BSON 的灵活 NoSQL 文档数据库，适合处理动态的非结构化数据，并通过横向分片实现更强的可扩展性。最终在 PostgreSQL 与 MongoDB 之间做出选择，取决于您项目的数据结构、可扩展性需求以及一致性要求。
PostgreSQL 与 MongoDB 的数据模型架构
让我们从数据模型架构的角度分析 PostgreSQL 与 MongoDB 的主要差异。
关系型与文档型结构
像 PostgreSQL 这样的关系型数据库管理系统将数据组织为表，每个表由行和列构成。这些表可通过键相互关联，从而通过SQL 连接（join）与高效查询实现复杂的数据关系。
关系型数据库。来源：DataCamp
凭借其简洁性、独特效率和强一致性，关系型数据库在过去几十年里取得了巨大成功并被广泛采用。
然而，当您处理不适合整齐放入表格格式的非结构化数据（例如社交媒体帖子、传感器数据）或必须实现可扩展性时（即应用需要在众多服务器间横向扩展），它们可能并非最佳选择。
这正是 NoSQL 数据库登场之处。与关系型数据库不同，NoSQL 数据库无需固定的架构约束即可处理非结构化或半结构化数据。
具体而言，MongoDB 是一种所谓的文档数据库，是 NoSQL 数据库的一种类型，它使用称为 BSON（二进制 JSON）的格式，将数据存储在类 JSON 文档的集合中。简单来说，文档类似于 JSON 的键值对象，而 BSON 提供了用于存储和操作数据的额外能力。
MongoDB 如何以 BSON 存储数据。来源：DataCamp
BSON 的灵活特性使得可以创建动态的文档架构，其结构与数据可随时变化。我们将在下一小节进一步介绍。
架构演进模式
像 PostgreSQL 这样的关系型数据库提供了健壮的架构，一旦创建了表，就很难更改。如果您处理的数据是表格化的，并且进入应用的格式始终一致，这是一个很好的特性。然而，如果您要处理内容彼此可能不同的半结构化或非结构化数据（如社交媒体帖子或传感器数据），则可能需要一定的灵活性来消化数据。
与 PostgreSQL 相比，MongoDB 采用所谓的无架构（schema-less）设计，为处理多样且不断演进的数据提供了非凡的灵活性。MongoDB 的无架构设计将数据组织为文档与集合：
- 文档（Document）是数据的基本单元，由 BSON 键值对构成。文档可以包含字符串、数字、日期、数组，甚至其他嵌入式文档。这允许在单个文档内构建表示复杂关系的精巧数据模型，与大多数编程语言中对象的结构相契合。
- 集合（Collection）以更灵活的方式将相关文档分组，类似于表。集合不强制实施架构，因此文档可以具有不同的结构和字段。集合存在于 MongoDB 数据库中，每个数据库可以包含多个集合。
与传统关系型数据库不同，在那里添加新字段需要更改整个表结构；MongoDB 允许同一集合中的文档具有完全不同的字段和结构。这消除了对刚性架构的需求，使得在不强制统一的情况下更容易存储多样化数据。
PostgreSQL 与 MongoDB 的查询语言
无论您使用何种数据库，无论是 PostgreSQL 还是 MongoDB，您都需要学习相应的语言来与数据库通信与管理。在 PostgreSQL 中，这就是 SQL——一种极为流行、标准化且易用的编程语言。您可以通过我们的Introduction to SQL 课程入门。
相较之下，MongoDB 主要依赖其自身的 MongoDB 查询语言（MQL）来与数据库交互。不过，也可以使用其他流行编程语言（如 Python、C 和 Java）来连接并操作 MongoDB 数据库。
让我们分析 SQL 与 MQL 的主要差异。
SQL 与 MQL 的能力比较
与 MongoDB 相比，PostgreSQL 的一大优势在于使用 SQL。SQL（意为 “Structured Query Language”）是构建与维护关系型数据库的基础语言。
这是一种简单的、领域特定的编程语言，几乎被所有关系型数据库系统采用，如 MySQL、SQL Server、SQLite，当然还有 PostgreSQL。
SQL 功能极其强大，允许您执行各种数据操作，从数据检索与聚合，到数据清洗与连接操作。然而，在 PostgreSQL 中，可能性更大，因为 PostgreSQL 具备一组用于复杂分析的高级能力，包括：
- 函数与过程：PostgreSQL 支持创建函数与存储过程，可使用多种编程语言编写，增强数据库处理复杂操作的能力。
- 全文检索：PostgreSQL 提供强大的全文搜索能力，可高效地对文本数据执行搜索操作。
- JSON 支持：对 JSON 数据类型的广泛支持，使 PostgreSQL 能够有效处理半结构化数据，在一定程度上弥合了关系型与文档型数据库之间的差距。
相比之下，尽管 MongoDB 不依赖 SQL，但它具备强大的查询、索引与聚合能力，以及用于在文档数据库中插入、更新或删除信息的其他函数。因此，如果您熟悉 JSON 或 Python 字典，熟悉 MQL 语法并不需要太久。
MQL 专为应对文档的动态特性而设计。因此，与 SQL 相比，它是一种灵活性更高的语言。此外，由于文档可以嵌入其他文档，在 MongoDB 中通常无需使用关系型数据库中常见的复杂且低效的连接操作。
索引策略
索引是提升数据检索速度的数据库对象。它们充当指针，帮助快速定位表中的行，从而提升查询性能。
PostgreSQL 具备强大的索引能力，支持多种索引类型，包括：
- B-Tree 索引：默认且最常用的索引类型
- 哈希索引（Hash）：用于快速等值查询
- GIN 索引：用于索引 JSON、数组和全文检索
- GiST 索引：适用于几何或模糊搜索等复杂数据类型
- BRIN 索引：适用于大型、自然有序的数据（如时间序列日志）
- 表达式索引：基于函数或表达式创建的索引
- 部分索引：仅为部分行建立索引（有助于过滤）
MongoDB 也支持索引，以便在集合中查找文档而无需扫描集合中的所有文档。然而，其能力相对有限，缺乏如 PostgreSQL 等关系型数据库所具备的多样性与复杂度。包括：
- 单字段索引：对集合中文档的单个字段进行收集与排序。
- 复合索引：对集合中文档的两个或更多字段进行收集与排序。
- 多键索引：针对存储在数组中的数据建立索引并排序。
- 文本索引：支持对包含字符串内容的字段进行文本搜索查询。
- 哈希索引：支持哈希分片。哈希索引会对字段值的哈希进行索引。
在 SQL 与 NoSQL 数据库中使用索引是提升性能、缩短查询时间的关键，尤其针对大型数据集。
不过，请记住，添加索引也会对写入操作产生负面性能影响。对于写入远多于读取的表或集合，索引代价高昂，因为每次插入都必须同时更新相关索引。
MongoDB 与 PostgreSQL 的性能与可扩展性
MongoDB 与 PostgreSQL 都是出色的数据库工具，但不应仅凭属性来选择其一。您应始终结合用例的具体情况做出选择。基于此，让我们分析 MongoDB 与 PostgreSQL 在性能与可扩展性方面的差异。
事务处理
与其他流行的关系型数据库系统一样，PostgreSQL 通过其强大的类型系统与对 ACID（原子性、一致性、隔离性、持久性）事务的支持，确保高水平的数据完整性与数据质量。
ACID 事务是一组保证数据库事务可靠处理的属性。它们确保即使在发生错误、崩溃或并发访问的情况下，数据仍保持准确与安全。这些属性对于维持任何项目中的数据质量至关重要。
虽然 ACID 事务长期以来一直是关系型数据库中确保数据完整性的黄金标准，但像 MongoDB 这样的 NoSQL 数据库通常更强调灵活性与可扩展性，而非严格的事务一致性。这导致放宽了关系型数据库中的部分 ACID 属性。
例如，一些 MongoDB 部署优先采用最终一致性而非即时一致性，这意味着更改可能无法即时在所有节点上反映。这种在一致性、可用性与性能之间的权衡带来了更好的性能和可扩展性，但在设计依赖严格数据一致性的应用时需要谨慎考虑。
可扩展性模式
扩展涉及使用多种技术来应对数据量与流量的增长。简单来说，可以通过纵向扩展与横向扩展来实现。前者是指提升并向同一服务器添加资源以应对负载增加；后者则通过向分布式系统中添加更多服务器或节点来实现，从而提升容量。
PostgreSQL 主要依赖纵向扩展来提升容量。不过，与其他流行的 SQL 数据库不同，PostgreSQL 也允许通过分区实现横向扩展，但需要复杂的配置。您可以在我们的Improving Query Performance in PostgreSQL Course 课程中学习 PostgreSQL 分区的全部技术细节。
相比之下，在像 MongoDB 这样的 NoSQL 系统中，应对不断增长的数据流量与数据量的首选策略是横向扩展。MongoDB 旨在充分利用分片（sharding），这是一种将数据库划分为更小、更易管理的“分片（shard）”并将其分布到多个服务器上的技术，使系统能够处理大规模数据集和高流量。
请查看我们的Sharding vs Partitioning 文章，全面了解这些流行的扩展技术。
MongoDB 与 PostgreSQL：使用场景分析
现在我们已经了解了 PostgreSQL 与 MongoDB 的关键特性和优势，是时候分析它们更适用的场景了。
PostgreSQL 的理想场景
当您的项目需要：
- 强 一致性：确保所有用户在同一时间看到相同的数据。
- 复杂 查询：从多个表连接数据以获取洞见。
- 高级分析：如果需要在数据库内执行复杂计算或数据转换，PostgreSQL 的可扩展性将大有裨益。
- 可扩展性：对于预期将大幅增长的项目，PostgreSQL 能通过纵向扩展或分区处理大型数据集，这是一个重要优势。
- ACID 合规：为关键应用保证可靠的事务处理。
举几个有说服力的例子，PostgreSQL 非常适用于：
- 金融交易：在转账或处理支付时，准确性与一致性至关重要。
- 库存系统：确保准确更新库存水平，对于避免超卖或差异非常关键。
- 订单处理：在电商中，为满足客户需求，必须正确且一致地处理订单。
MongoDB 的最佳实现
当需要灵活的数据结构以动态适配新信息与新架构、当可扩展性与性能重要、以及处理非结构化数据时，MongoDB 表现最佳。MongoDB 的无架构设计与横向扩展相结合，使其非常适用于以下用例：
- 社交媒体信息流：由于大量输入数据是非结构化且不可预测的，对数据一致性的要求较低；只要系统保持响应，帖子或点赞出现临时不一致是可接受的。
- 内容分发网络：优先以尽可能低的延迟向用户提供内容，而非一致性。
混合架构
在某些用例中，您可能需要结合 MongoDB 与 PostgreSQL 的优势，以构建能满足多样数据需求的综合解决方案。将 SQL 与 NoSQL 数据库组合为混合架构是可行的；如果您既需要事务的强一致性，又需要一定的灵活性，这是一个不错的主意。
例如，您可以在实时分析中使用 MongoDB 进行快速写入，同时使用 PostgreSQL 处理复杂的关系型操作并存储结构化数据。不过，目前并不存在将两种数据库功能“合并”的方式。您只是同时使用两种不同的数据库，这会增加系统复杂性，因此在实施前需要谨慎评估。
迁移注意事项
如果您计划将数据从 MongoDB 迁移到 PostgreSQL，或反之，您需要考虑以下几个方面：
数据库架构
如果您从 MongoDB 迁移到 PostgreSQL，在迁移数据之前，您需要创建一个或多个具有预定义架构的表，即包含指定数据类型与潜在约束的列清单。如果您要将数据迁入 Mongo，则需要定义如何将数据整合进文档中。尽管文档具有灵活性，仍需要一定的数据建模来安置现有数据。
潜在的数据转换
您要导出的数据可能不符合期望格式。在这种情况下，在迁移之前，您需要建立某种数据管道，将数据转换为正确格式后再插入到 PostgreSQL 或 MongoDB 数据库中。
如何迁移数据
执行迁移有多种方式。对于基础的导出/导入步骤，您可以手动完成，但这可能耗时、复杂且容易出错，尤其在要迁移的数据库包含大量数据时。因此，选择 ELT 工具完成这项工作可能是更好的方案。市面上有许多可用解决方案，无论是从 PostgreSQL 迁移到 Mondo 还是反向迁移。
性能优化
在迁移过程中考虑提升性能的技术至关重要，尤其是在复杂的迁移中。根据源与目标的不同，PostgreSQL 与 MongoDB 提供了加速流程的特定技术与策略，包括连接池、分区、分片键选择以及覆盖查询。
安全与合规
保护数据库部署对于确保数据完整性、可用性与合规性至关重要。MongoDB 与 PostgreSQL 均提供多种方法来保护您的数据库。本节将介绍一些最常见的技术。
认证机制
PostgreSQL 提供一系列认证方法，并可通过角色进行有效管理。角色是可拥有数据库对象并具有数据库权限的实体。角色可用于认证、权限管理与定义用户访问级别。在 PostgreSQL 中，角色既可作为用户，也可作为用户组。
您也可以在 MongoDB 中创建角色以防止未授权访问。基于角色的控制遵循最小权限原则，以最大限度降低安全风险。MongoDB 提供多种认证机制，其中加盐质询响应认证机制（SCRAM）是默认的基于密码的安全认证机制。
加密实践
MongoDB 提供多种数据加密实践来保护您的数据，包括：
- TLS/SSL 加密：使用 TLS/SSL 加密传输中的数据，确保客户端与数据库之间的通信安全。
- IP 白名单与 VPN：仅允许受信任的 IP 地址访问您的 MongoDB 实例。为增强安全性，可使用 VPN 为访问生产数据库创建安全隧道。
- 静态数据加密：您可以使用 MongoDB 在 WiredTiger 存储引擎中的原生支持来启用静态数据加密，以保护磁盘上存储的敏感数据。
- 客户端字段级加密：对于高安全性要求，可使用客户端字段级加密在将特定字段发送到数据库之前进行加密，确保即使数据库管理员也无法访问敏感信息。
至于 PostgreSQL，它同样在多个层面提供加密，并为防止因数据库服务器被盗、不当管理员行为及不安全网络导致的数据泄露提供了灵活的保护选项。部分选项包括：
- 密码加密：数据库用户密码可作为哈希存储，因此管理员无法得知分配给用户的实际密码。
- 网络传输数据加密：SSL 连接会加密通过网络发送的所有数据：包括密码、查询与返回的数据。
- 数据分区加密：可在文件系统层或分区层执行存储加密。
- SSL 主机认证：客户端与服务器可互相提供 SSL 证书。
社区与生态
MongoDB 与 PostgreSQL 都是非常流行的工具，拥有不断壮大的用户社区与繁荣的生态系统。让我们来看一看。
扩展能力
PostgreSQL 的扩展是扩展数据库能力的附加模块，类似于 Python 或 R 的包。近年来，丰富的扩展生态不断涌现，在各类场景、学科与用例中增强 PostgreSQL 的潜力。大多数扩展可在PostgreSQL Extension Network 中找到。
相比之下，MongoDB 的扩展集较为有限，主要集中在使 MongoDB 能与其他技术与框架协作，例如 Visual Studio Code 等 IDE 与 Google Cloud 等云系统。不过，针对您通常用于管理 MongoDB 的不同编程语言，也可能有其他第三方包可用。
采纳趋势
两者目前都处于黄金发展期，下图基于 DB-Engines 的数据展示了数据库引擎的趋势。
来源：db-engines
尽管关系型数据库管理系统仍占主导地位（包括排名第 4 的 PostgreSQL），图中也显示出近年的显著变化：MongoDB 与 Redis 等 NoSQL 数据库增长强劲。这一上升趋势反映了为管理非结构化数据与适应高并发应用而日益采用这些灵活且可扩展解决方案的现实。
PostgreSQL 与 MongoDB 对比表
下表简要总结了 MongoDB 与 PostgreSQL 之间的差异：
|
特性
|
MongoDB
|
PostgreSQL
|
|
数据结构
|
以文档（如 JSON、BSON）形式存储数据，支持灵活的分层结构。
|
将数据存储在具有行和列的表中，遵循预定义的架构。
|
|
架构灵活性
|
无架构：文档可以有不同结构，允许不同字段与数据类型。
|
固定架构：需要具有特定列与数据类型的预定义架构。
|
|
查询语言
|
使用基于对象、更加灵活的 MongoDB 查询语言（MQL）或类似语言。
|
使用 SQL（结构化查询语言）对结构化数据进行查询。
|
|
连接（Join）
|
通过在文档内嵌相关数据（反规范化）来避免连接。
|
支持跨表的复杂连接（规范化）。
|
|
性能
|
对非结构化或半结构化数据的读写更快，避免了连接带来的开销。
|
在结构化数据上具备强劲性能，但连接可能会拖慢查询。
|
|
可扩展性
|
横向可扩展：可通过分片将数据分布到多台服务器。
|
通常纵向可扩展：依赖更强大的硬件，尽管也有一定的横向扩展支持（如分区）。
|
|
事务支持
|
支持跨文档的 ACID 事务（自 MongoDB 4.0+），但最初并非为事务操作而设计。
|
完整支持符合 ACID 的事务，提供强一致性与高可靠性。
|
|
使用场景
|
最适合非结构化或半结构化数据，如用户画像、日志、目录与灵活的数据结构。
|
理想用于具有清晰关系的结构化数据，如财务记录或企业资源计划（ERP）。
|
|
数据关系
|
支持嵌入式数据（反规范化），便于通过单条查询获取相关信息。
|
关系型数据库依赖外键在表间建立关系（规范化）。
|
|
索引
|
支持索引，但缺乏关系型数据库所具备的多样与成熟的索引类型。
|
强大的索引能力，支持多种索引类型（如 B-tree、哈希），便于性能优化。
|
|
一致性
|
在分布式设置中提供最终一致性，同时在需要时也可提供强一致性（通过 ACID 事务）。
|
由于 ACID 事务与关系完整性，大多数情况下确保强一致性。
|
|
数据量扩展
|
通过增加服务器（分片）轻松扩展以容纳海量数据。
|
可进行纵向扩展，但横向扩展需要更复杂的配置（如分区）。
|
|
数据完整性
|
在每个文档内管理数据完整性，但管理文档间关系更具挑战。
|
通过主键与外键，以及 UNIQUE、NOT NULL 等约束提供强大的内建数据完整性支持。
|
|
开发者友好性
|
对开发者友好：数据建模灵活，适配现代应用（如 JSON、REST API）。
|
数据建模较为严格，但对熟悉 SQL 与结构化数据的开发者而言易于理解。
|
结论
MongoDB 与 PostgreSQL 是当今最受欢迎的两种数据库。它们分别是 SQL 与 NoSQL 数据库的优秀代表。通过对比，我们可以更清晰地了解两者的差异、优势以及各自适用的使用场景。
关于 SQL 与 NoSQL 数据库，还有很多值得学习的内容。在 DataCamp，我们希望通过最全面、最新的课程与教程帮助您进步。请查看以下数据库专题材料：
如果您正计划启动一个新的数字化应用，您很可能需要收集并存储一些数据。在哪里以及如何存储这些数据，是您必须做出的最重要决定之一，因为整个软件的运行都依赖这些数据。
传统上，数据以表格的形式存储，表中包含行和列，并通过某些关系（例如公共列）相互连接。存储关系型数据的数据库称为关系型数据库，或 SQL 数据库，因为大多数（如果不是全部）操作都依赖 SQL 来完成。
然而，近几十年来，为了应对每秒产生的数据量与多样性的快速增长，新的数据库管理系统不断发展。所谓的 NoSQL 数据库（Not only SQL）基于特定用例提出了新的模式与策略，以更有效地收集数据，同时在一定程度上仍依赖 SQL。
在本文中，我们将分析两种流行的数据库管理系统：PostgreSQL 与 MongoDB。前者是最受欢迎的 SQL 数据库之一，后者则是最著名的 NoSQL 数据库。
我们将介绍两种数据库的关键特性与优势、最具代表性的使用场景，以及在考虑将数据迁移到其中任一数据库时需要注意的要点。
如果您希望动手实践并尝试每种方法，务必查看我们的课程 Creating PostgreSQL Databases 和 Introduction to MongoDB in Python。
要点速览：PostgreSQL vs MongoDB
为任何数字化应用选择合适的数据库至关重要。PostgreSQL 作为基于 SQL 的强大关系型数据库，在需要一致性、复杂连接与 ACID 事务的结构化数据场景中表现出色。MongoDB 是一种使用 BSON 的灵活 NoSQL 文档数据库，适合处理动态的非结构化数据，并通过横向分片实现更强的可扩展性。最终在 PostgreSQL 与 MongoDB 之间做出选择，取决于您项目的数据结构、可扩展性需求以及一致性要求。
PostgreSQL 与 MongoDB 的数据模型架构
让我们从数据模型架构的角度分析 PostgreSQL 与 MongoDB 的主要差异。
关系型与文档型结构
像 PostgreSQL 这样的关系型数据库管理系统将数据组织为表，每个表由行和列构成。这些表可通过键相互关联，从而通过SQL 连接（join）与高效查询实现复杂的数据关系。
关系型数据库。来源：DataCamp
凭借其简洁性、独特效率和强一致性，关系型数据库在过去几十年里取得了巨大成功并被广泛采用。
然而，当您处理不适合整齐放入表格格式的非结构化数据（例如社交媒体帖子、传感器数据）或必须实现可扩展性时（即应用需要在众多服务器间横向扩展），它们可能并非最佳选择。
这正是 NoSQL 数据库登场之处。与关系型数据库不同，NoSQL 数据库无需固定的架构约束即可处理非结构化或半结构化数据。
具体而言，MongoDB 是一种所谓的文档数据库，是 NoSQL 数据库的一种类型，它使用称为 BSON（二进制 JSON）的格式，将数据存储在类 JSON 文档的集合中。简单来说，文档类似于 JSON 的键值对象，而 BSON 提供了用于存储和操作数据的额外能力。
MongoDB 如何以 BSON 存储数据。来源：DataCamp
BSON 的灵活特性使得可以创建动态的文档架构，其结构与数据可随时变化。我们将在下一小节进一步介绍。
架构演进模式
像 PostgreSQL 这样的关系型数据库提供了健壮的架构，一旦创建了表，就很难更改。如果您处理的数据是表格化的，并且进入应用的格式始终一致，这是一个很好的特性。然而，如果您要处理内容彼此可能不同的半结构化或非结构化数据（如社交媒体帖子或传感器数据），则可能需要一定的灵活性来消化数据。
与 PostgreSQL 相比，MongoDB 采用所谓的无架构（schema-less）设计，为处理多样且不断演进的数据提供了非凡的灵活性。MongoDB 的无架构设计将数据组织为文档与集合：
与传统关系型数据库不同，在那里添加新字段需要更改整个表结构；MongoDB 允许同一集合中的文档具有完全不同的字段和结构。这消除了对刚性架构的需求，使得在不强制统一的情况下更容易存储多样化数据。
PostgreSQL 与 MongoDB 的查询语言
无论您使用何种数据库，无论是 PostgreSQL 还是 MongoDB，您都需要学习相应的语言来与数据库通信与管理。在 PostgreSQL 中，这就是 SQL——一种极为流行、标准化且易用的编程语言。您可以通过我们的Introduction to SQL 课程入门。
相较之下，MongoDB 主要依赖其自身的 MongoDB 查询语言（MQL）来与数据库交互。不过，也可以使用其他流行编程语言（如 Python、C 和 Java）来连接并操作 MongoDB 数据库。
让我们分析 SQL 与 MQL 的主要差异。
SQL 与 MQL 的能力比较
与 MongoDB 相比，PostgreSQL 的一大优势在于使用 SQL。SQL（意为 “Structured Query Language”）是构建与维护关系型数据库的基础语言。
这是一种简单的、领域特定的编程语言，几乎被所有关系型数据库系统采用，如 MySQL、SQL Server、SQLite，当然还有 PostgreSQL。
SQL 功能极其强大，允许您执行各种数据操作，从数据检索与聚合，到数据清洗与连接操作。然而，在 PostgreSQL 中，可能性更大，因为 PostgreSQL 具备一组用于复杂分析的高级能力，包括：
相比之下，尽管 MongoDB 不依赖 SQL，但它具备强大的查询、索引与聚合能力，以及用于在文档数据库中插入、更新或删除信息的其他函数。因此，如果您熟悉 JSON 或 Python 字典，熟悉 MQL 语法并不需要太久。
MQL 专为应对文档的动态特性而设计。因此，与 SQL 相比，它是一种灵活性更高的语言。此外，由于文档可以嵌入其他文档，在 MongoDB 中通常无需使用关系型数据库中常见的复杂且低效的连接操作。
索引策略
索引是提升数据检索速度的数据库对象。它们充当指针，帮助快速定位表中的行，从而提升查询性能。
PostgreSQL 具备强大的索引能力，支持多种索引类型，包括：
MongoDB 也支持索引，以便在集合中查找文档而无需扫描集合中的所有文档。然而，其能力相对有限，缺乏如 PostgreSQL 等关系型数据库所具备的多样性与复杂度。包括：
在 SQL 与 NoSQL 数据库中使用索引是提升性能、缩短查询时间的关键，尤其针对大型数据集。
不过，请记住，添加索引也会对写入操作产生负面性能影响。对于写入远多于读取的表或集合，索引代价高昂，因为每次插入都必须同时更新相关索引。
MongoDB 与 PostgreSQL 的性能与可扩展性
MongoDB 与 PostgreSQL 都是出色的数据库工具，但不应仅凭属性来选择其一。您应始终结合用例的具体情况做出选择。基于此，让我们分析 MongoDB 与 PostgreSQL 在性能与可扩展性方面的差异。
事务处理
与其他流行的关系型数据库系统一样，PostgreSQL 通过其强大的类型系统与对 ACID（原子性、一致性、隔离性、持久性）事务的支持，确保高水平的数据完整性与数据质量。
ACID 事务是一组保证数据库事务可靠处理的属性。它们确保即使在发生错误、崩溃或并发访问的情况下，数据仍保持准确与安全。这些属性对于维持任何项目中的数据质量至关重要。
虽然 ACID 事务长期以来一直是关系型数据库中确保数据完整性的黄金标准，但像 MongoDB 这样的 NoSQL 数据库通常更强调灵活性与可扩展性，而非严格的事务一致性。这导致放宽了关系型数据库中的部分 ACID 属性。
例如，一些 MongoDB 部署优先采用最终一致性而非即时一致性，这意味着更改可能无法即时在所有节点上反映。这种在一致性、可用性与性能之间的权衡带来了更好的性能和可扩展性，但在设计依赖严格数据一致性的应用时需要谨慎考虑。
可扩展性模式
扩展涉及使用多种技术来应对数据量与流量的增长。简单来说，可以通过纵向扩展与横向扩展来实现。前者是指提升并向同一服务器添加资源以应对负载增加；后者则通过向分布式系统中添加更多服务器或节点来实现，从而提升容量。
PostgreSQL 主要依赖纵向扩展来提升容量。不过，与其他流行的 SQL 数据库不同，PostgreSQL 也允许通过分区实现横向扩展，但需要复杂的配置。您可以在我们的Improving Query Performance in PostgreSQL Course 课程中学习 PostgreSQL 分区的全部技术细节。
相比之下，在像 MongoDB 这样的 NoSQL 系统中，应对不断增长的数据流量与数据量的首选策略是横向扩展。MongoDB 旨在充分利用分片（sharding），这是一种将数据库划分为更小、更易管理的“分片（shard）”并将其分布到多个服务器上的技术，使系统能够处理大规模数据集和高流量。
请查看我们的Sharding vs Partitioning 文章，全面了解这些流行的扩展技术。
MongoDB 与 PostgreSQL：使用场景分析
现在我们已经了解了 PostgreSQL 与 MongoDB 的关键特性和优势，是时候分析它们更适用的场景了。
PostgreSQL 的理想场景
当您的项目需要：
举几个有说服力的例子，PostgreSQL 非常适用于：
MongoDB 的最佳实现
当需要灵活的数据结构以动态适配新信息与新架构、当可扩展性与性能重要、以及处理非结构化数据时，MongoDB 表现最佳。MongoDB 的无架构设计与横向扩展相结合，使其非常适用于以下用例：
混合架构
在某些用例中，您可能需要结合 MongoDB 与 PostgreSQL 的优势，以构建能满足多样数据需求的综合解决方案。将 SQL 与 NoSQL 数据库组合为混合架构是可行的；如果您既需要事务的强一致性，又需要一定的灵活性，这是一个不错的主意。
例如，您可以在实时分析中使用 MongoDB 进行快速写入，同时使用 PostgreSQL 处理复杂的关系型操作并存储结构化数据。不过，目前并不存在将两种数据库功能“合并”的方式。您只是同时使用两种不同的数据库，这会增加系统复杂性，因此在实施前需要谨慎评估。
迁移注意事项
如果您计划将数据从 MongoDB 迁移到 PostgreSQL，或反之，您需要考虑以下几个方面：
数据库架构
如果您从 MongoDB 迁移到 PostgreSQL，在迁移数据之前，您需要创建一个或多个具有预定义架构的表，即包含指定数据类型与潜在约束的列清单。如果您要将数据迁入 Mongo，则需要定义如何将数据整合进文档中。尽管文档具有灵活性，仍需要一定的数据建模来安置现有数据。
潜在的数据转换
您要导出的数据可能不符合期望格式。在这种情况下，在迁移之前，您需要建立某种数据管道，将数据转换为正确格式后再插入到 PostgreSQL 或 MongoDB 数据库中。
如何迁移数据
执行迁移有多种方式。对于基础的导出/导入步骤，您可以手动完成，但这可能耗时、复杂且容易出错，尤其在要迁移的数据库包含大量数据时。因此，选择 ELT 工具完成这项工作可能是更好的方案。市面上有许多可用解决方案，无论是从 PostgreSQL 迁移到 Mondo 还是反向迁移。
性能优化
在迁移过程中考虑提升性能的技术至关重要，尤其是在复杂的迁移中。根据源与目标的不同，PostgreSQL 与 MongoDB 提供了加速流程的特定技术与策略，包括连接池、分区、分片键选择以及覆盖查询。
安全与合规
保护数据库部署对于确保数据完整性、可用性与合规性至关重要。MongoDB 与 PostgreSQL 均提供多种方法来保护您的数据库。本节将介绍一些最常见的技术。
认证机制
PostgreSQL 提供一系列认证方法，并可通过角色进行有效管理。角色是可拥有数据库对象并具有数据库权限的实体。角色可用于认证、权限管理与定义用户访问级别。在 PostgreSQL 中，角色既可作为用户，也可作为用户组。
您也可以在 MongoDB 中创建角色以防止未授权访问。基于角色的控制遵循最小权限原则，以最大限度降低安全风险。MongoDB 提供多种认证机制，其中加盐质询响应认证机制（SCRAM）是默认的基于密码的安全认证机制。
加密实践
MongoDB 提供多种数据加密实践来保护您的数据，包括：
至于 PostgreSQL，它同样在多个层面提供加密，并为防止因数据库服务器被盗、不当管理员行为及不安全网络导致的数据泄露提供了灵活的保护选项。部分选项包括：
社区与生态
MongoDB 与 PostgreSQL 都是非常流行的工具，拥有不断壮大的用户社区与繁荣的生态系统。让我们来看一看。
扩展能力
PostgreSQL 的扩展是扩展数据库能力的附加模块，类似于 Python 或 R 的包。近年来，丰富的扩展生态不断涌现，在各类场景、学科与用例中增强 PostgreSQL 的潜力。大多数扩展可在PostgreSQL Extension Network 中找到。
相比之下，MongoDB 的扩展集较为有限，主要集中在使 MongoDB 能与其他技术与框架协作，例如 Visual Studio Code 等 IDE 与 Google Cloud 等云系统。不过，针对您通常用于管理 MongoDB 的不同编程语言，也可能有其他第三方包可用。
采纳趋势
两者目前都处于黄金发展期，下图基于 DB-Engines 的数据展示了数据库引擎的趋势。
来源：db-engines
尽管关系型数据库管理系统仍占主导地位（包括排名第 4 的 PostgreSQL），图中也显示出近年的显著变化：MongoDB 与 Redis 等 NoSQL 数据库增长强劲。这一上升趋势反映了为管理非结构化数据与适应高并发应用而日益采用这些灵活且可扩展解决方案的现实。
PostgreSQL 与 MongoDB 对比表
下表简要总结了 MongoDB 与 PostgreSQL 之间的差异：
特性
MongoDB
PostgreSQL
数据结构
以文档（如 JSON、BSON）形式存储数据，支持灵活的分层结构。
将数据存储在具有行和列的表中，遵循预定义的架构。
架构灵活性
无架构：文档可以有不同结构，允许不同字段与数据类型。
固定架构：需要具有特定列与数据类型的预定义架构。
查询语言
使用基于对象、更加灵活的 MongoDB 查询语言（MQL）或类似语言。
使用 SQL（结构化查询语言）对结构化数据进行查询。
连接（Join）
通过在文档内嵌相关数据（反规范化）来避免连接。
支持跨表的复杂连接（规范化）。
性能
对非结构化或半结构化数据的读写更快，避免了连接带来的开销。
在结构化数据上具备强劲性能，但连接可能会拖慢查询。
可扩展性
横向可扩展：可通过分片将数据分布到多台服务器。
通常纵向可扩展：依赖更强大的硬件，尽管也有一定的横向扩展支持（如分区）。
事务支持
支持跨文档的 ACID 事务（自 MongoDB 4.0+），但最初并非为事务操作而设计。
完整支持符合 ACID 的事务，提供强一致性与高可靠性。
使用场景
最适合非结构化或半结构化数据，如用户画像、日志、目录与灵活的数据结构。
理想用于具有清晰关系的结构化数据，如财务记录或企业资源计划（ERP）。
数据关系
支持嵌入式数据（反规范化），便于通过单条查询获取相关信息。
关系型数据库依赖外键在表间建立关系（规范化）。
索引
支持索引，但缺乏关系型数据库所具备的多样与成熟的索引类型。
强大的索引能力，支持多种索引类型（如 B-tree、哈希），便于性能优化。
一致性
在分布式设置中提供最终一致性，同时在需要时也可提供强一致性（通过 ACID 事务）。
由于 ACID 事务与关系完整性，大多数情况下确保强一致性。
数据量扩展
通过增加服务器（分片）轻松扩展以容纳海量数据。
可进行纵向扩展，但横向扩展需要更复杂的配置（如分区）。
数据完整性
在每个文档内管理数据完整性，但管理文档间关系更具挑战。
通过主键与外键，以及 UNIQUE、NOT NULL 等约束提供强大的内建数据完整性支持。
开发者友好性
对开发者友好：数据建模灵活，适配现代应用（如 JSON、REST API）。
数据建模较为严格，但对熟悉 SQL 与结构化数据的开发者而言易于理解。
结论
MongoDB 与 PostgreSQL 是当今最受欢迎的两种数据库。它们分别是 SQL 与 NoSQL 数据库的优秀代表。通过对比，我们可以更清晰地了解两者的差异、优势以及各自适用的使用场景。
关于 SQL 与 NoSQL 数据库，还有很多值得学习的内容。在 DataCamp，我们希望通过最全面、最新的课程与教程帮助您进步。请查看以下数据库专题材料：