Meteor框架性能与基于跳过（分页）的大量订阅

从这个

从Meteor 0.7.2开始，我们对大多数查询使用OplogObserveDriver。那里 有几种类型的查询仍然使用PollingObservedDriver：

• 指定跳过选项的查询

这意味着当您使用基于

skip

的分页时，可能总是在您需要分页机制的时候，如果您有许多用户可以导航的记录，它将使用旧的非常低效的轮询和差异算法

在我看来，Meteor仅仅适用于一些有限类型的应用程序，这些应用程序只需要很少几个ppl就可以协同工作，还可以进行一些实时更改

如果我有堆栈溢出，它会非常慢，因为每个客户端可能位于不同的页面上，这意味着每次添加/删除新消息时都会重新运行1000个查询，因为meteor无法从mongo oplog读取

skip

操作符影响的查询

---

我说的对吗？

有很多不基于skip的分页方法。因为您有一些排序顺序（否则您不会以任何有意义的方式分页），所以您可以说“根据此排序顺序给我下50个大于此值的项”

例如，如果您有如下分页查询：

Posts.find({ author: "Nick" }, { sort: { timestamp: -1 }, limit: 50, skip: 200 })

Posts.find({ author: "Nick", timestamp: { $gt: X } }, { sort: { timestamp: -1 }, limit: 50 })

您可以不使用

跳过
这样重写它：

Posts.find({ author: "Nick" }, { sort: { timestamp: -1 }, limit: 50, skip: 200 })

Posts.find({ author: "Nick", timestamp: { $gt: X } }, { sort: { timestamp: -1 }, limit: 50 })

其中，
X
是最后一次看到的帖子的时间戳。
有很多方法可以不基于跳过来分页。因为您有一些排序顺序（否则您不会以任何有意义的方式分页），所以您可以说“根据此排序顺序，给我下50个大于此值的项目”`@imslavko：您是对的，这会有所帮助。把它作为答案，这样我就可以接受了。你也可以把问题的标题改为与
skip
选项更相关的内容。我正在考虑这个问题，如果你有一些时间戳相同的文档（可能发生这种情况），但它们不在同一页上，这将是一个问题。