在我们开始之前:MongoDB和Postgres都是很好的数据库管理系统。这篇文章的目的是让你快速了解每个数据库的个性，以及每个数据库最适合的用例类型。

MongoDB和PostgreSQL:一个简单的比较

MongoDB是主要的文档数据库。它构建在分布式、向外扩展的架构上，并已成为一个用于管理和向应用程序交付数据的综合云平台。MongoDB可以大规模地处理事务、操作和分析工作负载。如果您关心的是上市时间、开发人员的生产力、支持DevOps和敏捷方法，以及构建无需操作操作就可伸缩的东西，那么MongoDB就是最好的选择。

PostgreSQL是一个坚如磐石的、开放源码的企业级SQL数据库，30年来一直在扩展它的功能。你想从关系数据库中得到的所有东西都可以在PostgreSQL中找到，它依赖于一个扩展的架构。如果您关心的是兼容性，从数百个表中提供数千个查询，利用现有的SQL技能，并将SQL推到极限，PostgreSQL将会做得非常出色。

这两个数据库都很棒，但是您需要什么呢?

作为一个精明的读者应该已经知道，真正的问题不是MongoDB和Postgres，而是最好的文档数据库和最好的关系数据库。两个数据库都很棒。

如果您正在为处理快速变化、多结构数据的现代事务和分析应用程序寻找分布式数据库，那么MongoDB就是最佳选择。

如果SQL数据库符合您的需要，那么Postgres是一个很好的选择。

你需要的正确答案当然是基于你正在尝试做的事情。在本文中，我们的目标是帮助解释每个数据库的个性和特征，以便您更好地了解它是否满足您的需要。

但是通常在开发项目的开始阶段，项目负责人通常很好地掌握了用例，但是对于他们的业务和用户将需要的具体应用程序特性并不是很清楚。他们不得不打赌谁最适合。本文的其余部分旨在提供有助于进行安全打赌的信息。

Postgresql vs MongoDB概述

但是，对于那些想要马上了解故事的人，这里是我们的一般指导的一个总结:

• 如果你在一个开发项目的开始阶段，试图通过敏捷的开发过程找出你的需求和数据模型，MongoDB将会大出风头，因为开发人员可以在他们需要的时候，自己重塑数据。MongoDB允许您管理任何结构的数据，而不仅仅是预先定义的表格结构。
  
• 如果你支持一个应用程序，你知道它需要扩展流量或数据大小(或两者都需要)，并且需要跨区域分布数据本地或数据主权，MongoDB的扩展架构将自动满足这些需求。
  
• 如果你想要一个在每个公共云上都以相同方式工作的多云数据库，可以在特定的地理区域存储客户数据，并支持最新的无服务器和移动开发范例，MongoDB Atlas是正确的选择。
  
• 如果你是一个SQL商店，引入一个新的范例所花费的成本比上面提到的任何好处都要高，那么PostgreSQL是一个很可能满足你所有需求的选择。
  
• 如果你想要一个关系数据库，运行复杂的SQL查询，并与许多现有的基于表格、关系数据模型的应用程序一起工作，PostgreSQL可以完成这项工作。
  
• 如果你是一个创造性的SQL开发人员和想把SQL索引限制通过使用先进的技术,存储和搜索大量的结构化数据类型,创建用户定义的函数在不同的语言中,和调优数据库第n个学位,你可能能够更进一步,比任何其他RDBMS PostgreSQL。
  

所以，现在不耐心的人已经得到了满足，患者可以深入到MongoDB，然后是PostgreSQL，然后进行比较。

MongoDB:可伸缩的文档数据库，已成为一个数据平台

文档模型的美丽之处

MongoDB的文档数据模型自然地映射到应用程序代码中的对象，使得开发人员可以很容易地学习和使用它。文档使您能够表示层次关系，从而方便地存储数组和其他更复杂的结构。JSON文档可以将数据存储在字段中，作为数组，甚至作为嵌套的子文档。这样就可以将相关信息存储在一起，通过丰富而富有表现力的MongoDB查询语言进行快速查询访问。

MongoDB以名为BSON(二进制JSON)的二进制表示形式将数据存储为文档。字段可以因文档而异;不需要向系统声明文档的结构—文档是自描述的。如果需要将新字段添加到文档中，那么可以在不影响集合中的所有其他文档的情况下创建该字段，不需要更新中央系统目录、更新ORM，也不需要使系统脱机。可选地，模式验证可用于对每个集合实施数据治理控制。

这种灵活性在合并来自不同来源的信息或适应随时间变化的文档时非常有用，特别是在不断部署新的应用程序功能时。

PostgreSQL和MongoDB的术语和概念

MongoDB的文档模型中使用的许多术语和概念与PostgreSQL的表格模型相同或相似:

文档模型的增强

MongoDB允许您以几乎任何结构存储数据，并且每个字段——甚至是那些嵌套在子文档和数组中的字段——都可以建立索引并有效地搜索。

MongoDB向文档模型和查询引擎添加元素，以处理数据的地理空间和时间序列标记。这扩展了可以在数据库上执行的查询和分析类型。

BSON包含了JSON数据中没有的数据类型(例如，datetime、int、long、date、浮点数、decimal128和字节数组)，提供了对多种数字类型的严格类型处理，而不是通用的“数字”类型。

模式验证允许您对模式应用治理和数据质量控制。

用于对许多文档进行更改的ACID事务

ACID事务是关系数据库中使编写应用程序更加容易的最强大的特性之一。关于如何定义和实现ACID事务的细节充斥着许多计算机科学教科书。计算机科学领域的许多讨论都是关于数据库事务中的隔离级别的)。PostgreSQL默认为read committed隔离级别，并允许用户将其调优到serializable隔离级别。

需要记住的重要事情是，事务允许在组中对数据库进行许多更改或在组中回滚。

在关系数据库中，所涉及的数据将在表模式中跨独立的父-子表建模。这意味着一次更新所有记录将需要一个事务。

从某种意义上说，文档数据库更容易实现事务，因为它们将数据聚集在文档中，而写和读文档是原子操作，因此不需要多文档事务。可以在单个操作中写入一个或多个字段，包括对多个子文档和数组元素的更新。MongoDB保证了文档更新时的完全隔离。任何错误都将触发更新操作回滚，恢复更改并确保客户端接收到文档的一致视图。

MongoDB还支持跨多个文档的数据库事务，因此相关的大块更改可以作为一个组提交或回滚。凭借其多文档事务功能，MongoDB是少数几个将传统关系数据库的ACID保证与文档模型的速度、灵活性和强大功能结合起来的数据库之一。

从程序员的角度来看，MongoDB中的事务就像开发人员在PostgreSQL中已经熟悉的事务一样。MongoDB中的事务是多语句的，具有与快照隔离类似的语法(例如starttransaction和committransaction)，因此对于任何有事务经验的人来说都很容易添加到任何应用程序中。

比较MongoDB查询语言和SQL

PostgreSQL使用的关系数据库模型依赖于将数据存储在表中，然后使用结构化查询语言(SQL)进行数据库访问。

要做到这一点，在PostgreSQL和所有其他SQL数据库中，必须在填充数据之前创建数据库模式和建立数据关系。相关信息可以存储在不同的表中，但是通过使用外键和连接进行关联。模式中的大多数更改都需要迁移过程，迁移过程可能会使数据库离线或降低应用程序在运行时的性能。

SQL的强大之处在于它的强大且广为人知的查询语言，以及大量的工具。

使用关系数据库的挑战是需要预先定义其结构。加载数据后更改结构通常非常困难，需要跨开发、DBA和Ops的多个团队紧密地协调更改。

现在在MongoDB的文档数据库世界中，数据的结构不需要预先在数据库中规划，而且更改起来更容易。开发人员可以决定应用程序中需要什么，并相应地在数据库中更改它。

MongoDB默认不使用SQL。相反，为了处理MongoDB中的文档并提取数据，MongoDB提供了自己的查询语言(MQL)，它提供了与SQL相同的大部分功能和灵活性。例如，与SQL一样，MQL允许您引用来自多个表的数据，转换和聚合这些数据，并筛选所需的特定结果。与SQL不同，MQL的工作方式对于每种编程语言都是惯用的。

MongoDB中的查询性能可以通过在文档和子文档的字段上创建索引来提高。MongoDB允许文档的任何字段，包括那些深深嵌套在数组和子文档中的字段，被建立索引并有效地查询。

下面的图表比较了SQL和MongoDB查询数据的方法，并展示了一些SQL语句的例子以及它们如何映射到MongoDB:

查询语言映射

PostgreSQL和MongoDB都有丰富的查询语言。下面是一些SQL语句的示例以及它们如何映射到MongoDB。在MongoDB文档中可以找到更全面的语句列表。

查看这些资源来进行更多的比较:

• SQL to MongoDB Mapping chart
  
• SQL to Aggregation Mapping chart
  

敏捷性和协作

文档模型还具有突出的特性，使开发和协作更容易、更快。

从开发人员个人的角度来看，MongoDB使数据更像代码。开发人员可以定义JSON或BSON文档的结构、进行一些开发、查看如何进行、随时添加新字段并随意修改数据，这就是文档模型的美妙之处。这种灵活性避免了要求DBA重新构造数据定义语言语句，然后重新创建和加载关系数据库，或者让开发人员做这些工作所带来的延迟和瓶颈。

在文档数据库中，开发人员或团队可以拥有文档或文档的一部分，并根据需要对其进行改进，而不需要在不同的团队之间使用中介和复杂的依赖链。

可伸缩性、弹性和安全性

MongoDB是为向外扩展而构建的。因此，需要超级快速查询和大量数据(或者两者都需要)的用例可以通过由小型机器组成更大的集群来处理。

MongoDB基于分布式架构，允许用户跨多个实例向外扩展，并被证明可以支持大型应用程序，无论是通过用户还是数据大小来衡量。向外扩展策略依赖于使用大量较小且通常廉价的机器。这种策略可以扩展到数百台机器。

在PostgreSQL中，扩展的方法取决于你说的是写数据还是读数据。对于写，它是基于一个扩展的架构，在这个架构中，运行PostgreSQL的单个主机器必须尽可能强大才能扩展。对于读取，可以通过创建副本扩展PostgreSQL，但是每个副本必须包含数据库的完整副本。

MongoDB可伸缩的基础是集群中跨实例智能分区(分片)数据的思想。MongoDB不分解文档;文档是独立的单元，这使得它更容易分布在多个服务器上，同时保持数据的局部性。

在完全管理的全球MongoDB地图集云服务中，跨地区分发数据很容易。某些文档可以被标记，因此它们将总是物理地存储在特定的国家或地理区域。这样的位置感知可以:

• 通过将数据存储在目标用户附近来减少延迟
  
• 帮助遵守有关数据可能被合法存储的地方的法律
  

每个MongoDB碎片都作为一个副本集运行:一个由三个或多个独立服务器组成的同步集群，在它们之间不断复制数据，提供冗余，并在面临系统故障或计划维护时防止停机。还可以跨数据中心安装副本，从而提供针对区域中断的弹性。在MongoDB Atlas中，创建和配置这样的集群变得更加容易和快速。

MongoDB已经实现了一套现代化的网络安全控制和集成，包括内部版本和云版本。这包括强大的安全范例，如客户端字段级加密，它允许在数据通过网络发送到数据库之前对其进行加密。

PostgreSQL有完整的安全特性，包括许多类型的加密。所有主要的云服务提供商都提供了PostgreSQL。虽然数据库是相同的，但操作和开发人员工具因云供应商的不同而不同，这使得不同云之间的迁移更加复杂。MongoDB Atlas以相同的方式运行在所有三大云提供商之间，简化了迁移和多云部署。

成熟的平台生态系统

随着数据库等基础技术的发展，它将得到由服务、集成、合作伙伴和相关产品组成的平台生态系统的支持。MongoDB平台生态系统的中心是数据库，但它有许多层，提供附加价值和解决问题。

MongoDB已经被大量采用，并且是最流行的现代数据库，根据Stackoverflow开发人员调查，它是开发人员最想使用的数据库。多亏了MongoDB工程和社区的努力，我们已经建立了一个完整的平台来满足开发者的需求。

PostgreSQL可以作为一个安装的、自管理的版本，或者作为一个数据库即服务在所有领先的云服务提供商上运行。每一个实现都按照创建它们的云提供商所希望的方式工作。要获得对PostgreSQL的支持，你必须使用云版本或者第三方提供的专门服务

MongoDB有以下几种形式:

• MongoDB Atlas是一个数据库即服务的产品，运行在所有主要的云平台上(AWS、微软Azure和谷歌云平台)。
  
• MongoDB Community edition是一个开放的免费数据库，可以安装在Linux、Windows或Mac OS上。
  
• MongoDB企业版基于MongoDB社区版，附加的功能只能通过MongoDB企业高级订阅获得。Enterprise Advanced包括对MongoDB部署的全面支持。它还添加了面向企业的特性，如LDAP和Kerberos支持、磁盘加密、审计和操作工具。MongoDB Enterprise可以安装在Linux、Windows或Mac OS上。
  

此外，MongoDB支持多种编程语言。为十多种语言提供了本地的惯用驱动程序——社区还构建了更多的驱动程序——支持特别查询、实时聚合和富索引，以提供强大的编程方法来访问和分析任何结构的数据。

MongoDB有一个强大的开发者社区，它代表了从爱好者到最具创新性的初创企业到最大的企业和政府机构的每个人，包括众多的系统集成商和顾问，他们提供广泛的商业服务。

MongoDB Atlas也通过MongoDB Realm进行了扩展，以简化应用程序开发，通过Lucene提供的Atlas搜索，以及支持在云对象存储上构建的数据湖的特性。

PostgreSQL和MongoDB都有强大的开发人员和顾问社区，他们随时准备提供帮助。

MongoDB的适合目的

在开发的这个阶段，MongoDB提供了业界领先的可伸缩性、弹性、安全性和性能:但它的最佳位置在哪里呢?

MongoDB擅长处理现代应用程序和api生成的数据结构，理想的定位是支持敏捷、快速变化的当今开发实践的开发周期。

真正的问题是你的数据最终会是什么样子。如果数据与应用程序代码中的对象一致，那么就可以很容易地用文档表示它。MongoDB在开发和生产中都是一个很好的选择，特别是当你需要扩展的时候。

但是，如果您有许多基于关系数据模型的现有应用程序，并且团队只熟悉SQL，那么像MongoDB这样的文档数据库可能不太合适。

文档数据库可以进行连接，但是它们与多页SQL语句不同，多页SQL语句有时是必需的，通常由BI工具自动生成。也就是说，MongoDB确实有一个ODBC连接器，允许SQL访问，主要来自BI工具。

Posrgresql:一个现代的SQL数据库

和Linux一样，PostgreSQL是一个管理良好的开源项目的例子。作为采用最广泛的关系数据库之一，PostgreSQL起源于1986年加州大学伯克利分校的POSTGRES项目，并随着时代的发展而发展。

PostgreSQL是一个对象关系数据库

PostgreSQL自称是一个开源的对象关系数据库系统。

它是一个SQL数据库，它有一些处理索引、增加并发性和实现优化和性能增强的策略，包括高级索引、表分区和其他机制。

PostgreSQL的对象部分与许多扩展相关，这些扩展使它能够包含其他数据类型，如JSON数据对象、键/值存储和XML。

核心SQL支持

PostgreSQL的设计原则强调SQL和关系表，并允许扩展性。

PostgreSQL提供了许多方法来提高数据库的效率，但在其核心上它使用了一种扩展策略。

像MySQL和其他开放源码关系数据库一样，PostgreSQL已经在许多行业中被证明是具有高要求用例的坩埚。

在我们进行比较的主要问题之前，让我们先介绍一下PostgreSQL的一些优势:什么时候表格、关系模型和sql最适合应用程序?

PostgreSQL采取了一种实用的、工程思维的方法来处理几乎所有的事情。例如，考虑以下关于符合最新SQL标准的声明:

“PostgreSQL试图遵循SQL标准，这样的一致性不会与传统特性相冲突，也不会导致糟糕的架构决策。”

对他们有利。正如他们正确指出的那样:

“在撰写本文时，没有任何关系数据库完全符合本标准。”

在SQL的世界中，有很好的SQL引擎，可以很好地处理一组简单的查询，也有更健壮的SQL引擎，带有查询优化器，可以处理复杂的查询，并且总是能够得到正确的结果。PostgreSQL是一个健壮的SQL引擎。

这种稳健性来自于长期的稳定发展。一个应该给SQL迷留下深刻印象的细节是，它支持“SQL标准中定义的所有事务隔离级别，包括serializable”。“这是一个工程水平，大多数长期使用的商业数据库都不会为此烦恼，因为它很难以足够的性能实现。”

性能、安全性和可靠性

因为PostgreSQL依赖于一个扩展策略来扩展写入或数据量，所以它必须充分利用可用的计算资源。PostgreSQL通过各种索引和并发策略来实现这一点。

PostgreSQL提供了各种强大的索引类型来最佳匹配给定的查询工作负载。索引策略包括b -树、多列、表达式和部分，以及高级索引技术，如GiST、SP-Gist、KNN GiST、GIN、BRIN、覆盖索引和bloom过滤器。

除了一个成熟的查询规划器和优化器，PostgreSQL还提供了性能优化，包括并行化读取查询、表分区和即时(JIT)表达式编译。

该数据库遵守广泛的安全标准，并具有许多特性来支持可靠性、备份和灾难恢复(通常通过第三方工具)。

可扩展性

PostgreSQL支持多种方式的可扩展性，包括存储函数和过程，从过程性语言(如PL/PGSQL、Perl、Python等)访问，SQL/JSON路径表达式，以及使用标准SQL接口连接到其他数据库或流的外部数据包装器。

许多扩展提供了额外的功能，包括PostGIS，一个用于地理空间分析的模块。

领导和标准化

因为PostgreSQL被广泛使用，所以可以肯定的是，大多数开发工具和其他系统都已经用它进行过测试，并且是兼容的。

PostgreSQL所采取的将语言的api连接到它的数据库的方法已经被许多其他数据库模仿，使得运行在PostgreSQL上的程序更容易移动到另一个SQL数据库上，反之亦然。

PostgreSQL是符合目的的

正如我们在开始所说的，问题不是“MongoDB vs PostgreSQL?”而是“什么时候使用文档数据库vs关系数据库有意义?”因为每个数据库都是其特定数据库格式的最佳版本。

SQL的优点包括为使用SQL数据库而构建的工具、集成和编程语言的庞大生态系统。您可以很容易地找到帮助，使您的SQL数据库项目在一般情况下和PostgreSQL项目在特定情况下工作。PostgreSQL还有很多部署选项。

MongoDB还是PostgreSQL?

放弃SQL意味着离开已经使用SQL的大型技术生态系统。如果您正在开发一个新的应用程序，或者计划对现有的应用程序进行现代化，那么这样做会更容易。

许多数据管理和BI工具都依赖于SQL，并以编程的方式生成复杂的SQL语句，以便从数据库中获得正确的数据集合。PostgreSQL在这种情况下做得很好，因为它是一个健壮的、企业级的实现，被许多开发人员理解。

此外，如果您有一个扁平的、表格式的数据模型，它不会经常更改，也不需要向外扩展，那么关系数据库和SQL可能是一个强大的选择。

但是，必须考虑SQL的预期好处带来的成本。

与MongoDB相比，PostgreSQL的缺点是它依赖于关系数据模型，而这种模型对开发人员在代码中使用的数据结构不友好，而且必须提前定义，因此每当需求发生变化时，开发进度就会变慢。

MongoDB之所以能够很好地支持快速、迭代的开发周期，是因为文档数据库在开发人员的控制下将数据转换为代码。这种速度被关系数据库中使用的严格的表格数据模型的性质所破坏，数据库管理员通常必须通过一个中间过程对其进行重塑，从而降低了整个开发过程。这样的瓶颈会阻碍创新。

当一个应用程序上线时，PostgreSQL用户必须准备好与可伸缩性进行斗争。PostgreSQL使用了一种扩展策略。这意味着在某些情况下，对于高性能用例来说，您可能会遇到瓶颈，或者不得不转移资源，通过缓存或反规范化数据或使用其他策略来寻找其他扩展方法。

在MongoDB中，这类技术通常是不需要的，因为通过本地分片内置了可伸缩性，支持水平向外扩展的方法。在正确分片集群之后，您总是可以添加更多实例并继续向外扩展。MongoDB Atlas拥有广阔的多云、全球感知的平台随时待命，一切为您全面管理。

PostgreSQL可以支持复制，但自动故障转移等更高级的功能必须由独立于数据库开发的第三方产品支持。这种方法比MongoDB内置的自修复功能更复杂，运行速度更慢，无缝性也更差。

您的数据模型将走向何处?

您的数据和目标用例的性质也非常重要。那些拥有大量SQL技能和工具的生态系统以及大量现有应用程序的用户可以选择继续使用关系数据模型。

但是MongoDB已经成功了，尤其是在企业中，因为它打开了通向开发人员生产力新水平的大门，而静态关系表常常带来障碍。如果您有需要大规模交付的数据，那么可以从开发人员对模式的控制中获益，或者满足您一开始并不能完全理解的需求，那么像MongoDB这样的文档数据库就很适合。

MongoDB和PostgreSQL都是优秀的数据库。我们希望这次讨论能给您一些新的启发，使您能更好地满足您的需要。