文档数据库提供多种优势，包括：
- 直观的数据模型，开发者可以快速轻松地使用
- 灵活的架构，允许数据模型随着应用程序需求的变化而演变
- 横向扩展的能力
凭借这些优势，文档数据库成为了通用数据库，可用于各种用例和行业。
文档数据库属于非关系型数据库，也称为 NoSQL 数据库。文档数据库不使用固定的行列结构存储数据，而是采用灵活的文档结构。文档数据库是表格式关系数据库的一种常见替代方案。详细了解 NoSQL 数据库。
目录：
- 文档是什么？
- 文档型数据库的关键特性是什么？
- 文档数据库与关系数据库有何不同？
- 文档比表格更容易处理吗？
- 文档型数据库与其他数据库之间的关系是什么？
- 为什么不直接在关系数据库中使用 JSON？
- 文档数据库的优点和缺点是什么？
- 文档数据库的有哪些应用场景？
文档是什么？
文档是文档数据库中的记录。文档通常存储有关一个对象及其相关元数据的的信息。
文档将数据存储在字段值对中。值可以是各种类型和结构，包括字符串、数字、日期、数组或对象。文档可以存储为 JSON、BSON 和 XML 等格式。
以下是一个 JSON 文档，其中存储了名为 Tom 的用户的信息。
集合
集合是一组文档。一个集合通常存储内容相似的文档。
集合中的所有文档不一定都需要具有相同的字段，因为文档数据库具有灵活的模式。 请注意，某些文档数据库提供 模式验证，因此可以在需要时选择锁定模式。
继续上面的示例，包含关于 Tom 信息的文档可以存储在名为 users 的集合中。可以向 users 集合中添加更多文档，以存储其他用户的信息。例如，下面存储有关 Donna 信息的文档可以添加到 users 集合中。
请注意，Donna 和 Tom 的文档包含的字段并不完全相同。users 集合采用灵活的模式，存储每位用户的相关信息。
增删改查操作
文档数据库通常具有 API 或查询语言，可允许开发者执行 CRUD（创建、读取、更新和删除）操作。
- 创建：可以在数据库中创建文档。每个文档都有一个唯一标识符。
- 读取：可以从数据库中读取文档。 API 或查询语言允许开发者使用文档的唯一标识符或字段值来查询文档。 可以向数据库添加索引以提高读取性能。
- 更新：现有文档可以全部或部分更新。
- 删除：可以从数据库中删除文档。
文档型数据库的关键特性是什么？
文档数据库具有以下关键特性：
- 文档模型：数据存储在文档中，而不像其他数据库那样采用表或图结构。文档能够自然映射到大多数常用编程语言中的对象，帮助开发者快速构建应用程序。
- 灵活的模式：文档数据库采用灵活的模式，一个集合中的文档不必包含完全相同的字段。请注意，部分文档数据库支持模式验证，因此可以根据需要对模式施加限制。
- 分布式和弹性： 文档数据库是分布式的，可实现水平扩展（通常比垂直扩展的成本更低）和数据分布。文档数据库通过复制提供弹性。
- 通过 API 或查询语言进行查询： 文档数据库提供 API 或查询语言，可允许开发者在数据库上执行 CRUD 操作。 开发者有能力根据唯一标识符或字段值来查询文档。
文档数据库与关系数据库有何不同？
文档数据库与关系数据库主要有以下三个方面的区别：
- 数据模型的直观性：文档映射到代码中的对象，因此使用起来更加自然。无需将数据分解到多个表中，运行成本高昂的连接操作或集成单独的对象关系映射 (ORM) 层。共同访问的数据存储在一起，因此开发者可以编写更少的代码，让最终用户获得更好的性能。
- JSON 文档的普及性： JSON 已成为数据交换和存储的既定标准。 JSON 文档轻量、与语言无关且易于人类阅读。 文档是所有其他数据模型的超集，因此开发者可以根据其应用程序的需求来构建数据 — 丰富的对象、键值对、表格、地理空间和时间序列数据，或图表的节点和边。
- 模式的灵活性： 文档的模式是动态且自描述的，因此开发者无需先在数据库中预先定义模式。 字段可能因文档而异。 开发者可以随时修改结构，从而避免造成破坏性影响的模式迁移。 一些文档数据库提供 模式验证 ，因此您可以选择性地实施约束文档结构的规则。
文档比表格更容易处理吗？
开发者通常发现，在文档中处理数据比在表格中处理数据更容易且更直观。文档映射到大多数常用编程语言中的数据结构。开发者在存储相关数据时不必担心手动将其拆分到多个表中，或在检索时将其重新合并。开发者也不需要使用 ORM 来处理数据操作，而是可以轻松地直接在其应用程序中处理数据。
让我们再查看一个名为 Tom 的用户的文档。
用户(User)
关于 Tom 的所有信息都存储在一个文档中。
现在，让我们考虑如何将相同的信息存储在关系数据库中。我们首先创建一个存储用户基本信息的表。
用户(User)
用户可以喜欢很多内容（这意味着用户和喜欢之间存在一对多的关系），因此我们将创建一个名为“Likes”的新表来存储用户的喜欢。“Likes”表将具有一个外键，引用“Users”表中的 ID 列。
喜欢
同样，一位用户可以经营多家企业，因此我们将创建一个名为“Businesses”的新表，用于存储企业信息。Businesses 表将包含一个外键，用于引用 Users 表中的 ID 列。
业务
在这个简单的示例中，我们看到用户的相关数据可以存储在文档数据库的单个文档中，也可以存储在关系数据库的三个表中。当开发者想要在文档数据库中检索或更新用户信息时，他们可以编写一个无需连接的查询。与数据库的交互非常简单，数据库中的数据建模也很直观。
请访问 从 SQL 到 MongoDB 的术语和概念映射 了解详情。
文档型数据库与其他数据库之间的关系是什么？
文档模型是其他数据模型的超集，包括键值对、关系、对象、图表和地理空间。
- 键值对 可以通过文档中的字段和值进行建模。 文档中的任何字段都可以建立索引，从而为开发者在查询数据时提供更高的灵活性。
- 关系数据 可以通过将相关数据保存在单个文档中，使用嵌入式文档和数组，以不同的方式（有些人认为更直观的方式）进行建模。 相关数据也可以存储在单独的文档中，并且可以使用 数据库引用 来连接相关数据。
- 文档映射到大多数常用编程语言中的 对象。
- 图表节点和/或边可以建模为文档。 边缘也可以通过数据库引用进行建模。 可以使用 $graphLookup 等操作来运行图表查询。
- 地理空间 数据可以建模为文档中的数组。
由于其丰富的数据建模能力，文档数据库是通用数据库，可以存储多种使用案例的数据。
为什么不直接在关系数据库中使用 JSON？
随着文档数据库赋能开发者更加快速地构建应用，大多数关系数据库都增加了对 JSON 的支持。但是，简单地添加 JSON 数据类型并不能带来具有原生 JSON 支持的数据库的益处。为什么？这是因为关系方法降低了开发者的工作效率，而不是提高工作效率。这是开发者必须要面对的问题。
专有扩展：
处理文档数据时，往往需要使用特定供应商的专用 SQL 函数。大多数开发者并不熟悉这些函数，常用 SQL 工具也无法直接调用这些函数。再加上底层 JDBC/ODBC 驱动程序和 ORM，开发流程会更加复杂，开发效率也会下降。
原始数据处理
将 JSON 数据呈现为简单的字符串和数字，而不是像 MongoDB 这样的原生文档数据库支持的丰富数据类型，使得计算、比较和排序数据变得复杂且容易出错。
糟糕的数据质量和僵化的表格
关系数据库几乎无法验证文档模式，因此您难以对 JSON 数据实施质量控制。同时，您仍需为常规表格数据定义模式。随着应用程序功能迭代，每次修改表结构都会增加额外开销。
低性能
大多数关系数据库并不维护 JSON 数据的统计信息，从而阻止查询规划器优化针对文档的查询，以及阻碍您调优查询。
没有原生横向扩展
传统关系数据库不支持通过在多个实例之间对数据库进行分区（分片）来应对不断增长的工作负载。您只能在应用层自行实现分片，或依赖成本高昂的纵向扩展系统。
文档数据库的优点和缺点是什么？
文档数据库有许多优势：
- 文档模型应用广泛、直观易用，支持快速开发软件。
- The 灵活的模式 允许数据模型随着应用程序需求的变化而变化。
- 文档数据库具有丰富的 API 和查询语言，让开发者能够轻松与其数据进行交互。
- 文档数据库是 分布式的 （支持水平扩展和全球数据分布）并且 具有弹性。
这些优势使文档数据库成为通用数据库的绝佳选择。
人们常提到的文档数据库的一个常见弱点是，许多数据库不支持多文档 ACID 事务。 我们估计，利用 document model 的应用程序中，有 80%-90% 不需要使用多文档事务。
请注意，一些文档数据库（如 MongoDB）支持多文档 ACID 事务。
请参阅什么是 ACID 事务？，了解文档模型如何在很大程度上减少对多文档事务的需求，以及 MongoDB 如何在确有必要的少数场景中提供事务支持。
文档数据库的有哪些应用场景？
文档数据库是通用数据库，为事务和分析应用程序的多种使用案例提供服务：
- 单一视图或数据枢纽
- 客户数据管理和个性化
- 物联网（IoT）和时间序列数据
- 产品目录和内容管理
- 支付处理
- 移动应用程序
- 大型机负载分流
- 操作分析
- 实时分析
总结
文档数据库利用直观、灵活的文档数据模型来存储数据。 文档数据库是通用型数据库，可用于各种使用案例，适用范围涵盖 各个行业。
通过在 MongoDB Atlas（MongoDB 的数据平台）中创建数据库，开始使用文档数据库。Atlas 提供一个慷慨的永久免费套餐，您可以用来实验和探索文档模型。