此页面描述了一种数据模型,该数据模型使用嵌入式文档来描述所连接数据之间的一对一关系。将连接的数据嵌入单个文档中可以减少获取数据所需的读取操作次数。通常,您应该对架构进行结构设计,以便您的应用程序可以在一次读取操作中接收其所有必需的信息。
考虑以下映射顾客和地址关系的示例。该示例说明了如果您需要在另一个实体的上下文中查看一个数据实体,则与引用相比,嵌入的优势。在patron
和
address
数据之间的一对一关系中,address
属于patron
。
在规范化数据模型中,address
文档包含对该文档的引用patron
。
如果address
经常使用name
信息检索数据,然后使用引用,则您的应用程序需要发出多个查询来解析引用。更好的数据模型是将address
数据嵌入数据中patron
,如以下文档所示:
使用嵌入式数据模型,您的应用程序可以通过一个查询来检索完整的顾客信息。
嵌入式文档模式的潜在问题是,它可能导致大型文档包含应用程序不需要的字段。这些不必要的数据可能会导致服务器上的额外负载并减慢读取操作的速度。相反,您可以使用子集模式来检索在单个数据库调用中最常访问的数据子集。
考虑一个显示电影信息的应用程序。该数据库包含movie
具有以下架构的集合:
当前,该movie
集合包含应用程序不需要显示电影的简单概述的几个字段,例如
fullplot
和评级信息。可以将所有电影数据分为两个集合,而不是将所有电影数据存储在一个集合中:
该movie
集合包含有关电影的基本信息。这是应用程序默认加载的数据:
该movie_details
集合包含每个电影的其他较少访问的数据:
此方法提高了读取性能,因为它要求应用程序读取较少的数据来满足其最常见的请求。如果需要,应用程序可以进行额外的数据库调用以获取访问频率较低的数据。
小费
在考虑将数据拆分到哪里时,数据中最常访问的部分应该放在应用程序首先加载的集合中。
使用包含更频繁访问的数据的较小文档可以减小工作集的整体大小。这些较小的文档可提高读取性能,并为应用程序提供更多内存。
但是,了解您的应用程序及其加载数据的方式很重要。如果将数据不正确地拆分为多个集合,则应用程序通常将需要多次访问数据库,并依赖于JOIN
操作来检索其所需的所有数据。
此外,将数据分为多个小集合可能会增加所需的数据库维护,因为可能很难跟踪哪些数据存储在哪个集合中。