Service Fabric ReliableCollections 中是否有既定的分页模式

Question

在可靠的集合（特别是 IReliableDictionary）中，实现“常见”查询的一种方法是更新辅助字典，该字典构造要在枚举中以特定方式排序的键。对于大型数据集，我希望避免在.

为了实现这一点，我想实现某种延续令牌，调用者可以在请求数据时提供给我。我目前正在通过首先生成有序枚举并返回前 n 个项目来实现这一点，其中 n = MAX_PAGE 大小。 延续本质上是该 n 项列表中的最后一个键。下次调用者传入 continuation 标记时，我会生成有序的枚举，并使用过滤器函数指定键应大于 continuation。

这有两个问题（我可以看到）：

1. 该集合可以当主叫用户第一次请求一个页面，后续请求之间变化。我不确定我是否可以避免，因为无论谁试图翻阅数据，都需要能够随时更新集合。
2. 我不确定如何使用过滤器功能。我认为由于开发人员可以过滤任何内容，因此GetEnumerableAsync() 方法必须在返回 enumerable 之前提供字典中的所有键。对于足够大的数据集，这似乎很慢。

是否有任何规定的方法来分页数据？ 我开始觉得对于我的一些用例，我可能会用 Reliable Collections 挑错树。

Answer 1

构建二级索引的一种方法是使用Notifications。使用具有引用类型 TKey 和 TValue 的通知，您可以维护二级索引，而无需创建 TKey 或 TValue 的任何副本。

如果需要二级索引提供快照隔离，那么二级索引选择的数据结构必须实现多版本并发控制。

如果您没有这样的数据结构来承载二级索引，另一种选择是在分页客户端调用中保持事务和枚举的实时性。通过这种方式，您可以使用 Reliable Dictionary 的内置快照支持来提供对数据的分页一致扫描，而不会阻止写入。在这种情况下，令牌将是TransactionId，允许您的服务找到MoveNextAsync的相关枚举。使用此选项的缺点是 Reliable Dictionary 将无法修剪可能长时间运行的快照事务保持可见的值的旧版本。

为了减轻上述缺点，您可能希望限制正在进行的快照事务的数量，以及在您的服务处理枚举和相关读取事务之前客户端必须完成分页枚举的时间。

当使用带有键过滤器的CreateEnumerableAsync时，Reliable Dictionary 将为每个键调用过滤器，以查看它是否满足自定义过滤器。由于今天 TKeys 总是保存在内存中，对于大多数关键过滤器，我们在这里没有看到问题。枚举中最昂贵的部分往往是从磁盘检索分页值。