BigQuery 分页 - 使用 pageToken 或 startIndex？答案

【问题标题】：BigQuery Pagination - Use pageToken or startIndex?BigQuery 分页 - 使用 pageToken 或 startIndex？
【发布时间】：2019-05-14 12:33:47
【问题描述】：

我将在 BiqQuery 中获取大约 500,000 到 1,000,000 行。我们将其限制为偏移量和最大值。在这种情况下pageSize = max 和startIndex = offset。

我们的数据每天只会处理一次，然后上传到 BigQuery。

文档建议使用pageToken 而不是startIndex。我使用pageToken 和startIndex 做了一些估计，看不出有任何时间差异。

我在 StackOverflow 找到了一个答案：

“您应该使用从原始查询响应或之前的jobs.getQueryResults() 调用返回的页面令牌来迭代页面。这通常比使用基于索引的分页更有效和可靠”

但我不相信为什么要使用pageToken，那么我需要存储令牌以在来回时使用它。从时间上看，我看不出有什么不同。

【问题讨论】：

【解决方案1】：

但我不相信为什么我应该使用“pageToken”

两者之间有一些但很重要的区别

因此，如果在您的情况下您知道有多少结果并且您不关心页面大小，则可以使用基于索引的其他方式使用页面令牌

【讨论】：

我没有关注你。澄清一下，查询和分页是在我们的服务器端完成的。在这种情况下，我们的客户端浏览器 UI 将发送一个带有偏移量且 max=200 的 JSON 请求，然后响应将针对前 200 个。响应也将具有总数（3500 条记录）。客户端需要跟踪 jobId 和 pageToken。为了测试，我将 pageToken 存储在服务器端。要获取 queryResult，我使用 pageSize (200) 和 pageToken 来获取基于页面的行。我可以对基于索引的分页做同样的事情。
BigQuery 有一个您无法控制的 API 网络大小限制。这意味着即使您询问 100 行，由于大小的原因，您可能会得到 80 行。目的是确保您不会将大量数据下载到客户端。因此，如果在您的用例中您的数据量很小，您可以忽略这一点。
好的，现在我明白了，所以你永远无法保证你能返回多少行。我做了一个测试，从 100 000 中得到了 34157 行。但是你像 200 行一样安全吗，或者你永远不可能？谢谢。
我做了更多研究，这是来自link 的官方编号，最大响应大小 — 128 MB 压缩1 所以这完全取决于您的数据大小。希望您发现此答案有帮助，请考虑接受并投票:)