MongoDB模式设计 - 许多小文件或更少的大型文档？ [英] MongoDB Schema Design - Many small documents or fewer large documents?

问题描述

背景

我将原型从RDBMS数据库转换为MongoDB。虽然是非规范化，但似乎有两个选择，一个导致许多（数百万）较小的文档或一个导致更少（数十万）大文档的选择。

Background
I'm prototyping a conversion from our RDBMS database to MongoDB. While denormalizing, it seems as if I have two choices, one which leads to many (millions) of smaller documents or one which leads to fewer (hundreds of thousands) large documents.

如果我可以将其简化为一个简单的模拟，那么这样一个不太客观的文档（在Java中）就是区别：

If I could distill it down to a simple analog, it would be the difference between a collection with fewer Customer documents like this (in Java):

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

或包含许多付款文件的集合，如下所示：

or a collection with many, many Payment documents like this:

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

问题

MongoDB设计为喜欢许多，许多小文件还是较少的大文件？答案主要取决于我打算运行什么查询？ （即，客户X有多少张信用卡？vs上个月所有客户的平均金额是多少？）

Question
Is MongoDB designed to prefer many, many small documents or fewer large documents? Does the answer mostly depend on what queries I plan on running? (i.e. How many credit cards does customer X have? vs What was the average amount all customers paid last month?)

我已经看了很多，但我没有绊倒任何MongoDB模式最佳实践，这将有助于我回答我的问题。

I've looked around a lot but I didn't stumble into any MongoDB schema best practices that would help me answer my question.

推荐答案

你一定需要优化

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

Here's my best guess based on your description.

你可能会想知道每个客户的所有信用卡，所以保留客户对象中的数组。您也可能希望为每个付款提供客户参考。这将使支付文件保持相对较小。

You'll probably want to know all Credit Cards for each Customer, so keep an array of those within the Customer Object. You'll also probably want to have a Customer reference for each Payment. This will keep the Payment document relatively small.

Payment对象将自动拥有自己的ID和索引。您可能希望在客户参考中添加索引。

The Payment object will automatically have its own ID and index. You'll probably want to add an index on the Customer reference as well.

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

This will allow you to quickly search for Payments by Customer without storing the whole customer object every time.

如果您想回答问题，例如上个月所有客户的平均金额是多少，那么您就会想要一个映射/减少任何大型数据集。你没有得到这个回应实时。你会发现，存储一个参考给客户可能足够好这些地图减少。

If you want to answer questions like "What was the average amount all customers paid last month" you're instead going to want a map / reduce for any sizeable dataset. You're not getting this response "real-time". You'll find that storing a "reference" to Customer is probably good enough for these map-reduces.

所以直接回答你的问题： MongoDB设计希望许多，许多小文档或更少的大型文档？

So to answer your question directly: Is MongoDB designed to prefer many, many small documents or fewer large documents?

MongoDB旨在非常快速地查找索引条目。 MongoDB非常擅长在大型干草堆中找到一些针。 MongoDB不是非常擅长在干草堆中找到大多数针。因此，围绕您最常见的用例构建数据，并为罕见的用例编写映射/缩减作业。

MongoDB is designed to find indexed entries very quickly. MongoDB is very good at finding a few needles in a large haystack. MongoDB is not very good at finding most of the needles in the haystack. So build your data around your most common use cases and write map/reduce jobs for the rarer use cases.

这篇关于MongoDB模式设计 - 许多小文件或更少的大型文档？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！