如何通过meteor“追踪”mongo的大型收藏？

Question

我在mongo数据库中收集了一些日志类型的信息。我正在尝试找出最有效/最简单的“tail-f”方法，即在meteor应用程序中，当一个新文档被添加到集合中时，它应该被发送到客户端，客户端应该将其附加到集合中当前文档集的末尾。

客户端不会被发送，也不会保留集合中的所有文档，可能只是最后的大约100个文档。

现在，从Mongo的角度来看，我认为没有一种方式可以说“集合中的最后N个文档”，这样我们就根本不需要应用任何排序。似乎最好的选择是进行自然排序降序，然后进行限制调用，比如mongo文档中列出的$natural

db.collection.find().sort( { $natural: -1 } )

因此，在服务器端，AFAICT发布“最后100个文档”流星集合的方式类似于：

Meteor.publish('logmessages', function () {
  return LogMessages.find({}, { sort: { $natural: -1 }, limit: 100 });
});

现在，从“tail-f”的角度来看，这似乎具有将“最后100个文档”发送到服务器的正确效果，但这样做的顺序是错误的（最新的文档将在Meteor集合的开头，而不是结尾）。

在客户端，这似乎意味着需要（不幸的是）反向收集。现在，我在流星收藏文档中没有看到反向（）和按$Natural排序： 1在客户端上不起作用（这似乎是合理的，因为没有真正的Mongo上下文）。在某些情况下，消息在文档中会有时间戳，客户端可以根据时间戳进行排序，以获得“自然顺序”，但这似乎有点过时。

无论如何，我觉得我可能错过了一个更简单的方法，那就是从mongo通过meteor发布一个实时的“最后100个文档插入到收藏中”

谢谢！

编辑-看起来如果我将Mongo中的集合更改为有上限的集合，那么服务器可以创建一个可定制的游标，以高效（快速）地获得添加到集合中的新文档的通知。然而，我不清楚是否/如何通过流星集合让服务器这样做。

另一种似乎效率稍低但不需要切换到封顶集合（AFAICT）的方法是使用智能集合，它会跟踪oplog，因此至少它是事件驱动的，而不是轮询，而且由于源集合中的所有操作都是插入操作，所以它似乎仍然非常有效。不幸的是，AFAICT我仍然面临排序问题，因为我不知道如何将服务器端集合定义为“插入的最后100个文档”：(

如果有一种方法可以在Mongo中创建一个集合作为另一个查询（“物化视图”之类），那么也许我可以在Mongo中创建一个log-last-100“集合视图”，然后Meteor就可以发布/订阅整个伪集合了？

Answer 1

对于只插入数据，$natural应该可以得到与时间戳索引和排序相同的结果，所以这是个好主意。相反的事情是不幸的；我认为你有两个选择：

1. 使用$natural，自己倒过来做
2. 添加时间戳，仍使用$natural
3. 添加时间戳、按时间索引、排序

'#1'-对于100个项目，执行反向客户端应该是没有问题的，即使对于移动设备，这将从服务器卸载它。您可以使用. finch（）转换为数组，然后将其反转以维持顺序，而不需要使用时间戳。不过，你会在正常的数组土地上玩；没有更好的迷你蒙戈功能，所以在反转之前先做任何过滤。

“#2”-这一个很有趣，因为您不必使用索引，但仍然可以使用客户端上的时间戳对记录进行排序。这会让你在mini mongo土地上享受生活的乐趣。

#3--占用了db的空间，但这是最直接的

如果你不需要迷你蒙戈的功能（或者你自己做阵列过滤很舒服），那么#1可能是最好的。

不幸的是，MongoDB没有视图，因此无法实现您的log-last-100视图想法（尽管这是一个不错的功能）。

除此之外，请关注您的订阅生命周期，以便用户在不查看日志时不会在后台持续下拉日志更新。我可以看到这很快成为一个性能杀手。