1

我们的主表有 92 MBytes 和 410k 行。我们正在加入另一个具有 10KBytes 和 378 行的表。AppEngine 项目号：897138483898 BigQuery 项目号：1036887365938

我们有几个疑问。平均响应时间为 10 秒。平均最大/最小比率为 6.4。我们有定期的暂停。最小响应时间可以在 1.1 到 5 秒之间，平均为 3.7 秒。

如果我们有这些 92 MB 的响应时间变化......当我们使用真实数据时会发生什么？

我们能做什么？

        Klaus
4

2 回答 2

1

首先，我想说这比我预期的要差得多。我在 BigQuery 日志中查找了您的查询作业，您看到的问题似乎与高度碎片化的表有关。您正在执行的查询（或至少一个较慢的查询）引用了一个表，该表是在 4 天内以 900 多个单独的部分创建的。

BigQuery 有一个合并过程，该过程会定期运行以将像这样的表压缩成更少的块，但它已经停滞了几天。同时，您可以选择复制表格（您可以通过 BigQuery UI 或表格复制作业执行此操作）并使用复制的版本。这应该会导致 BigQuery 生成更紧凑的表示。

此外，默认情况下，AppEngine HTTP 请求会在 10 秒后超时。您可以增加此值。BigQuery 的jobs.query() 方法也会在同一时间后超时，也可以增加。（如果您认为这会有所帮助，我可以查找有关如何执行这两项操作的参考）。

于 2013-09-24T15:47:39.950 回答
0

非常感谢您的快速回答。正如您所建议的，我们将旧表选择为新表，删除旧表并使用旧名称再次选择。

现在平均响应时间为 2.2 秒，加速了 4.5 秒。平均最大/最小比率现在为 1.9，因此响应时间变化减少了 3.4 倍。最大响应时间为 5 秒。因此没有更多的超时。最小响应时间范围为 0.8 至 2.7 秒。w/平均1.6秒。

重建 BigQuery 似乎可以将响应时间变化减少 3.4 倍，并将平均响应时间加快 4.5 倍。

那太棒了！感谢您及时有效的帮助！

           Klaus
于 2013-09-26T12:11:21.030 回答