在stackoverflow的讨论和googlers的推荐下，我们努力实现bq表的每日分区策略，但是，我们面临一个问题，当分区超过30个时，需要更长的时间（可能是2-3次更多的）。所以 3 个月，是 90 个分区，即使在总共 1000 万行的小数据集上，它也比拥有 10m 行的事实慢两倍。当我们有 6 个月的时候会发生什么？
这是为什么？什么是正确的方法？
此外，我们看到 GAE 有时会在运行大查询大小的字符串时遇到问题，尽管文档声称限制非常大。
非常感谢
问问题
343 次
1 回答
1
我在事务数据日志方面遇到了类似的问题。起初我们尝试使用一个巨大的表来存储日常交易数据（对我们来说是秒数据）。我还发现了一些说使用表分区可以实现更好的性能的东西，但是当尝试按照您描述的那样进行操作时（按天），我们得到的性能比我们尝试使用一张大表时要差得多。
最后，经过反复试验，我们发现对我们来说最好的办法是每月进行一次表分区——这样可以获得更好的查询性能（几乎快两倍！）。显然，我认为这取决于您的查询（例如是否有连接等）以及您的应用程序的具体要求。对我们来说，一个业务规则是我们只存储价值 3 年的客户数据，因此在任何给定时间我们将拥有的最大分区表数为 36，但这可能不适合您的应用程序的需求。
注意 - 我们不在 GAE 上，我们只是通过脚本使用原始 BigQuery API，尽管我希望 GAE 托管应用程序的性能更好。
我还应该补充一点，我们的平均查询大约有 3000 万行，但数据本身并不是非常冗长（很多小字符串和 INT）
于 2013-07-06T00:04:30.713 回答