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

【问题标题】：Meteor framework performance with lots of subscription based on skip (pagination)基于跳过（分页）的大量订阅的 Meteor 框架性能
【发布时间】：2014-09-15 19:44:44
【问题描述】：

来自这个https://github.com/meteor/meteor/wiki/Oplog-Observe-Driver。

从 Meteor 0.7.2 开始，我们使用 OplogObserveDriver 进行大多数查询。那里有几种类型的查询仍在使用 PollingObserveDriver：

...

指定跳过选项的查询

...

这意味着总是当你使用基于skip的分页时，如果你有很多用户可以导航的记录，这可能总是你需要分页机制时，它将使用旧的非常低效的轮询和差异算法。

在我看来，Meteor 仍然适用于某些有限类型的应用程序，其中只有少数 ppl 需要协同工作并进行一些实时更改传播。

如果我有堆栈溢出的东西，它会很慢，因为每个客户端可能在不同的页面上，这意味着每次添加/删除新消息时重新运行例如 1000 个查询，因为流星无法读取mongo oplog 使用skip 运算符的查询受到影响。

我是对的？

【问题讨论】：

有很多不基于skip的分页方式。因为你有某种排序顺序（否则你不会以任何有意义的方式分页），你可以说“根据这个排序顺序给我接下来的 50 个大于这个值的项目”。
@imslavko：你是对的，这会有所帮助。把它作为答案，所以我可以接受。
您还可以将问题的标题更改为与skip 选项更相关的内容

标签： meteor

【解决方案1】：

有很多不基于跳过的分页方法。因为你有某种排序顺序（否则你不会以任何有意义的方式分页），你可以说“根据这个排序顺序给我接下来的 50 个大于这个值的项目”。

例如，如果您有这样的分页查询：

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

你可以像这样重写它而不用skip：

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

其中X 是上次看到帖子的时间戳。

【讨论】：

我正在考虑它，如果您有一些具有相同时间戳的文档（可能会发生）并且它们不在同一页面上，这将是一个问题。