首页 文章

如何最好地通过流星在mongo中收集大量的藏品?

提问于
浏览
10

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

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

现在,从Mongo的角度来看,我根本不需要应用任何类型 . 似乎最好的选择是进行自然排序降序,然后是限制调用,所以类似于the mongo doc on $natural中列出的内容

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集合的开头)而不是在最后) .

在客户端,这似乎意味着需要(不幸的是)反转集合 . 现在,我没有在the Meteor Collection docs中看到reverse()并按$ natural排序:1没有't work on the client (which seems reasonable, since there'没有真正的Mongo上下文 . 在某些情况下,消息将在文档中包含时间戳,并且客户端可以按此排序以使'natural order'返回,但这似乎有点hacky .

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

谢谢!

EDIT - 看起来如果我将Mongo中的集合更改为上限集合,那么服务器可以create a tailable cursor有效(并且快速)获得添加到集合中的新文档的通知 . 但是,我不清楚是否/如何通过Meteor集合让服务器这样做 .

一个看起来效率稍低但不需要切换到上限集合(AFAICT)的替代方法是使用Smart Collections,它会对oplog进行拖尾,所以至少它仍然非常有效.2666849_ d仍然非常高效 . 不幸的是,AFAICT I 'm still left with the sorting issues since I don't看到如何将服务器端集合定义为'last 100 documents inserted' . :(

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

1 回答

  • 3

    对于仅插入数据, $natural 应该为您提供与时间戳和排序索引相同的结果,这是一个好主意 . 相反的是不幸的;我想你有几个选择:

    • 使用$ natural并自行反转

    • 添加时间戳,仍然使用$ natural

    • 添加时间戳,按时间索引,排序

    '#1' - 对于100个项目,即使对于移动设备,执行反向客户端应该没有问题,并且将从服务器卸载它 . 您可以使用 .fetch() 转换为数组,然后将其反转以维护顺序,而无需使用时间戳 . 你会在正常的阵地中玩耍;没有更好的mini-mongo功能,所以在倒车之前先进行任何过滤 .

    '#2' - 这个很有趣,因为您不必使用索引,但您仍然可以使用客户端上的时间戳对记录进行排序 . 这为您提供了入住迷你蒙古土地的好处 .

    '#3' - 数据库上的成本空间,但它是最直接的

    如果你不需要mini-mongo的功能(或者自己很舒服地进行阵列过滤),那么#1可能是最好的 .

    不幸的是MongoDB没有视图,所以不能做你的log-last-100视图的想法(虽然这将是一个很好的功能) .

    除此之外,请密切注意您的订阅生命周期,以便用户在不查看日志时不会在后台持续下拉日志更新 . 我可以看到它迅速成为性能杀手 .

相关问题