Performance mongodb-针对大量数据点的推荐树结构

我正在从事一个项目，该项目记录多个地区的商品价格历史，我计划将数据存储在mongodb集合中

由于我对mongodb比较陌生，我很好奇对于相当大的数据量，建议使用什么样的文档结构。情况如下：

我正在记录200多个地区大约90000件商品的价格历史。我希望每小时记录每件商品的价格，并给出每件商品2周的历史记录。总计约为（90000*200*24*14）~=60亿个数据点，或每个项目约67200个数据点。清理查询将每天运行一次，以删除超过14天的记录（更具体地说，将其归档到gzip json/text文件）

就我将从中获得的数据而言，我主要对两件事感兴趣：1）特定地区特定商品的价格历史，以及2）所有地区特定商品的价格历史

在我真正开始导入这些数据并运行基准测试之前，我希望有人能够给出一些建议，告诉我应该如何构造这些数据，以便通过查询快速访问数据

我正在考虑以下结构：

{
    _id: 1234,
    data: [
        {
            territory: "A",
            price: 5678,
            time: 123456789
        },
        {
            territory: "B",
            price: 9876
            time: 123456789
        }
    ]
}

每个项目都是其自己的文件，每个地区/特定地区内该项目的价格点都有该文件。我遇到的问题是检索特定商品的价格历史记录。我相信我可以通过以下查询实现这一点：

db.collection.aggregate(
    {$unwind: "$data"},
    {$match: {_id: 1234, "data.territory": "B"}}

)

我考虑的另一种选择是将每个数据点放在自己的文档中，并在项目和区域上建立索引

// Document 1
{
    item: 1234,
    territory: "A",
    price: 5679,
    time: 123456789
}
// Document 2
{
    item: 1234,
    territory: "B",
    price: 9676,
    time: 123456789
 }

我只是不确定拥有60亿个包含3个索引的文档，还是拥有90000个文档（每个文档包含67200个数组对象）并使用聚合会更好地提高性能

---

或者，对于这个问题，你们这些优秀的人和MongoDB向导可以推荐一些其他的树结构或处理方法？

我会将文档结构为“给定区域内每固定时间间隔的产品价格”。整个模式的时间间隔是固定的，但是不同的模式来自不同的选择，对于您的应用程序来说，最好的模式可能需要通过测试来确定。将时间间隔选择为1小时将给出第二个模式想法，总共约60亿个文档。您可以选择时间间隔为2周（不要）。在我看来，最好的时间间隔是1天，所以文档应该是这样的

{
    "_id" : ObjectId(...), // could also use a combination of prod_id, terr_id, and time so you get a free unique index to look up by those 3 values
    "prod_id" : "DEADBEEF",
    "terr_id" : "FEEDBEAD",
    "time" : ISODate("2014-10-22T00:00:00.000Z"), // start of the day this document contains the data for
    "data" : [
        {
            "price" : 1234321,
            "time" : ISODate("2014-10-22T15:00:00.000Z") // start of the hour this data point is for
        },
        ...
    ]
}

我喜欢1天的时间间隔，因为它在文档数量（主要与索引大小有关）、文档大小（16MB限制，必须通过网络传输）和旧文档退役（保留15天，每天从15天开始擦除+存档）之间取得了很好的平衡。如果您在

{“prod_id”：1，“terr_id”：

}上放置索引，这应该可以让您高效地完成两个主要查询。通过为每天预先分配文档，以便更新到位，您可以获得额外的奖金性能提升

---

基于构建MMS监控系统的经验，有一个关于管理这样的时间序列数据的方法。我的想法基本上是从这里提出来的。

这有点主观，确实应该回答，但要问自己“将项目保存在一个数组中有什么好处？”。MongoDB中使用数组的一般想法是在以这种方式访问相关数据的地方将相关数据保存在一起。这意味着，如果使用单个文档并一起读/写所有或多个数组点，则使用数组。如果不是，那么数组不是最佳选择。销售订单和商品是一个很好的选择，但其他东西可能不是。