我有一个关于各种场景下 BQ 性能的问题，尤其是围绕“幕后”的并行化。
我每天保存 1 亿条记录。目前，我每 5 天轮换一次表，以避免因全表扫描而产生高额费用。
如果我要运行日期范围为“过去 30 天”的查询（例如），我将在 6 个（如果我在分区的最后一天）和 7 个表之间进行扫描。
作为替代方案，我可以每天将我的数据分区到一个新表中。在这种情况下，我将优化我的开支——因为我查询的数据永远不会比我拥有的更多。问题是，在将结果返回给客户端方面会遭受性能损失，因为我现在可能并行查询 30 或 90 或 365 个表（联合）。
总结一下：
谁能解释一下如何在成本和性能之间找到平衡？
【问题讨论】：
标签： google-bigquery
很大程度上取决于您如何编写查询以及多少开发成本，但数据量并不像一个障碍，因此您试图过早地进行优化。
当您加入大于 8MB 的表时，您需要使用 EACH 修饰符，并且该查询在内部是并行的。
这种分区意味着您可以获得更高的有效读取带宽，因为您可以从许多此类磁盘中并行读取。 Dremel 利用了这一点；当您运行查询时，它可以一次从数千个磁盘中读取您的数据。
BigQuery 在内部将表存储在 碎片；这些是可以并行处理的离散数据块。如果 你有一个 100 GB 的表，它可能存储在 5000 个分片中，这样就可以 由多达 5000 名工作人员并行处理。你不应该做任何假设 大约是表中分片数量的大小。 BigQuery 将重新分区 定期数据以优化存储和查询行为。
继续为每一天创建表，一个建议是编写您的创建/补丁脚本，该脚本在运行时为很远的将来创建表，例如：我现在每天创建接下来 12 个月的表。这比每天创建表格的脚本要好。并使其成为您的部署/配置脚本的一部分。
要阅读更多内容，请查看本书中的Chapter 11 ■ Managing Data Stored in BigQuery。
【讨论】：