2

我们在 Mongodb 中对我们的大部分集合进行版本控制。选择的版本控制机制如下：

{  "docId" : 174, "v" : 1,  "attr1": 165 }   /*version 1 */
{  "docId" : 174, "v" : 2,  "attr1": 165, "attr2": "A-1" } 
{  "docId" : 174, "v" : 3,  "attr1": 184, "attr2" : "A-1" }

因此，当我们执行查询时，我们总是需要以这种方式使用聚合框架来确保获取对象的最新版本：

db.docs.aggregate( [  
    {"$sort":{"docId":-1,"v":-1}},
    {"$group":{"_id":"$docId","doc":{"$first":"$$ROOT"}}}
    {"$match":{<query>}}
] );

这种方法的问题是，一旦你完成了分组，你在内存中有一组与你的集合无关的数据，因此你的索引不能被使用。

因此，您的集合拥有的文档越多，查询速度就越慢。

有什么办法可以加快这个速度吗？

如果没有，我会考虑转向这篇好文章中定义的一种方法：http ://www.askasya.com/post/trackversions/

4

1 回答 1

0

为了完成这个问题，我们选择了选项 3：一个集合保留最新版本，一个集合保留历史版本。它在这里介绍：http ://www.askasya.com/post/trackversions/并且可以在http://www.askasya.com/post/revisitversions/中找到一些进一步的描述（带有一些不错的代码片段） 。

它已经在生产中运行了 6 个月。到目前为止，一切都很好。前一种方法意味着我们总是使用聚合框架，一旦您修改原始模式（使用 $group、$project...），它就会远离索引，因为它不再与原始集合匹配。随着数据的增长，这让我们的表现变得很糟糕。

使用新方法虽然问题消失了。我们 90% 的查询都针对最新数据，这意味着我们以一个简单ObjectId的 as 标识符为目标的集合，我们不再需要聚合框架，只需常规查找即可。

我们对历史数据的查询总是包含这些数据id，version因此通过对这些数据进行索引（我们将两者都包含在内，_id以便我们开箱即用），对这些集合的读取速度同样快。这是一个不容忽视的问题。在设计集合/模式在 MongoDB 中的外观时，应用程序中的读取模式至关重要，因此您必须确保在做出此类决定时了解它们。

于 2018-01-21T11:47:36.807 回答