我有一个关于各种场景下BQ性能的问题，特别是围绕"底层"并行化的问题。
我每天保存100万条记录。目前，我每5天轮换一次桌子，以避免由于全桌子扫描而产生的高额费用。
如果我要运行一个日期范围为"最近30天"的查询(例如)，我将扫描6(如果我在分区的最后一天)到7个表之间。
作为一种替代方法，我可以每天将我的数据分区到一个新表中。在这种情况下，我将优化我的费用——因为我从来没有查询过比我拥有的更多的数据。问题是，在将结果返回给客户端方面，将遭受性能损失，因为我现在可能并行查询30或90或365个表(Union)。
总结:
- 更多的表=更少的数据扫描
- 更少的表=(?)对客户端的响应时间更长
谁能告诉我如何在成本和性能之间找到平衡?
这在很大程度上取决于你如何编写你的查询和多少开发成本，但数据量并不像一个障碍，因此你试图优化过早。
当JOIN大于8MB的表时，需要使用EACH修饰符，并且该查询是内部并行的。
这个分区意味着您可以获得更高的有效读带宽，因为您可以并行地从许多这些磁盘中读取数据。Dremel利用了这一点;当你运行一个查询时，它可以一次从数千个磁盘读取你的数据。
内部，BigQuery将表存储在碎片;这些是可以并行处理的离散数据块。如果你有一个100gb的表，它可能存储在5000个分片中，这是允许的由多达5000名工人并行处理。你不应该做任何假设关于表中分片数量的大小。BigQuery将重新分区定期数据，优化存储和查询行为。
继续为每天创建表，一个建议是编写你的create/patch脚本，在它运行时创建未来很远的表，例如:我现在为每天创建未来12个月的表。这比使用每天创建表的脚本要好。并将其作为部署/配置脚本的一部分。
阅读更多内容，请参阅第11章■管理BigQuery中存储的数据