如何最好通过流星'尾随-f'mongo中的大型集合？

Question

我在mongo数据库中有一个集合,我附加了一些日志记录类型的信息.我试图找出最有效/最简单的方法来"尾随-f"在流星应用程序中 - 当一个新文档被添加到集合中时,它应该发送给客户端,应该将它追加到最后集合中的当前文档集.

客户端不会被发送也不会保留集合中的所有文档,可能只是最后的~100左右.

现在,从Mongo的角度来看,我没有看到说"集合中的最后N个文档"的方式,因此我们根本不需要应用任何类型.似乎最好的选择是进行自然降序,然后是限制调用,所以类似于$ natural上的mongo doc中列出的内容

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

因此,在服务器端AFAICT发布这个'最后100个文件'Meteor集合的方式将是这样的:

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

现在,从'tail -f'的角度来看,这似乎具有将'最后100个文档'发送到服务器的正确效果,但是以错误的顺序发送(最新的文档将在Meteor集合的开头)而不是在最后).

在客户端,这似乎意味着需要(不幸的是)反转集合.现在,我没有在Meteor Collection文档中看到reverse()并按$ natural排序:1在客户端上不起作用(这似乎是合理的,因为没有真正的Mongo上下文).在某些情况下,消息将在文档中包含时间戳,并且客户端可以按此排序以获得"自然顺序",但这看起来有点像hacky.

在任何情况下,感觉我可能错过了一个更简单的方法,即从mongo通过流星发布的"最后100个文档插入集合"集合.:)

谢谢!

编辑 - 看起来如果我将Mongo中的集合更改为上限集合,那么服务器可以创建一个可用的光标,以便有效(并且快速)获得添加到集合中的新文档的通知.但是,我不清楚是否/如何通过Meteor集合让服务器这样做.

另一个似乎效率稍低但不需要切换到上限集合(AFAICT)的替代方案是使用智能集合来执行oplog的拖尾,因此至少它是事件驱动而不是轮询,并且因为源中的所有操作收集将是插入,似乎它仍然非常有效.不幸的是,AFAICT我仍然留下了排序问题,因为我没有看到如何将服务器端集合定义为"最后插入的100个文档".:(

如果有一种方法可以在Mongo中创建一个集合作为另一个集合的查询("物化视图"),那么也许我可以在Mongo中创建一个log-last-100"集合视图",然后Meteor将能够只是发布/订阅整个伪集合？

Answer 1

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

1. 使用 $natural 并自己执行相反的操作
2. 添加时间戳，仍然使用$natural
3. 添加时间戳、按时间索引、排序

'#1' - 对于 100 个项目，即使对于移动设备，在客户端执行反向操作也应该没有问题，这会从服务器上卸载它。您可以使用.fetch()转换为数组，然后反转它以维持顺序，而无需使用时间戳。不过，你将在正常的阵列区域中进行游戏；没有更多好的 mini-mongo 功能，因此在逆向之前先进行任何过滤。

'#2' - 这个很有趣，因为您不必使用索引，但您仍然可以使用客户端上的时间戳对记录进行排序。这给你带来了住在迷你蒙戈土地上的好处。

'#3' - 占用数据库空间，但它是最直接的

如果您不需要 mini-mongo 的功能（或者愿意自己进行数组过滤），那么#1 可能是最好的。

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

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