database-design - MongoDB Schema Design - 许多小文档还是更少的大文档？

Question

背景
我正在对从我们的 RDBMS 数据库到 MongoDB 的转换进行原型(prototype)设计。在进行非规范化时，似乎我有两种选择，一种会导致许多(数百万)个小文档，另一种会导致更少(数十万)个大文档。

如果我可以将其提炼成一个简单的类比，这将是具有较少客户文档的集合之间的区别(在 Java 中):

class Customer {    private String name;    private Address address;    // each CreditCard has hundreds of Payment instances    private Set<CreditCard> creditCards;}

或者一个包含很多很多这样的付款文档的集合:

class Payment {    private Customer customer;    private CreditCard creditCard;    private Date payDate;    private float payAmount;}

问题
MongoDB 的设计是偏爱很多很多小文档还是更少的大文档？答案是否主要取决于我计划运行的查询？ (即客户 X 有多少张信用卡？vs 所有客户上个月支付的平均金额是多少？)

我环顾四周，但没有偶然发现任何可以帮助我回答问题的 MongoDB 架构最佳实践。

Answer 1

您肯定需要针对正在执行的查询进行优化。

根据您的描述，这是我的最佳猜测。

您可能想知道每个客户的所有信用卡，因此请在客户对象中保留一个数组。您可能还希望每次付款都有一个客户引用。这将使支付文档相对较小。

支付对象将自动拥有自己的 ID 和索引。您可能还想在客户引用上添加一个索引。

这将允许您快速搜索客户付款，而无需每次都存储整个客户对象。

如果您想回答诸如“所有客户上个月支付的平均金额是多少”之类的问题，您将需要为任何大型数据集提供 map /减少。您没有“实时”获得此响应。您会发现存储对 Customer 的“引用”对于这些 map-reduce 来说可能已经足够了。

所以直接回答你的问题:MongoDB 是设计成偏爱很多很多小文档还是更少的大文档？

MongoDB 旨在非常快速地找到索引条目。 MongoDB 非常擅长大海捞针。 MongoDB 不是非常善于在大海捞针中找到大部分。因此，围绕您最常见的用例构建数据，并为罕见的用例编写 map/reduce 作业。