我有一些数据要按日期分区，并且还要按内部定义的客户端ID进行分区。
目前，我们使用table-per-date模型存储此数据。它工作得很好，但查询单个客户端ID的速度很慢且很昂贵。
我们考虑过为每个客户端ID创建一个表，并在这些表中使用日期分区。这里唯一的问题是，这将迫使我们每天招致数千个负载工作，并且还要提前通过客户端ID对数据进行分区。
这是我提出的潜在解决方案： - 使用每日表格方法（例如log_20170110） - 创建一个我们用作分区日期的虚拟日期列，并将该日期设置为-01-01（例如，对于客户端ID 1235，将_PARTITIONTIME设置为1235-01-01）
这将允许我们每天加载数据，正如我们现在所做的那样，将按日期对我们进行分区，并将利用日期分区功能按客户端ID进行分区。你能看出这种方法有什么问题吗？ BigQuery是否允许我们存储200年或5000年的数据？
PS：我们还可以使用将日期推迟到零后单一时间的方案，例如将2000添加到年份，或者将最后两位数字推送到月和日，例如1235 =＆gt; 2012-03-05
答案 0 :(得分：0)
BigQuery是否允许我们存储200年或5000年的数据？
是，00001-01-01和9999-12-31之间的任何日期
正式地说这是一个选择（顺便说一下取决于你计划/已经有多少客户）
在https://stackoverflow.com/a/41091896/5221944
了解有关相同想法的更多信息与此同时，我希望BigQuery能够很快通过任意字段进行分区。也许在2017年下半年 - 只是猜测：o）
答案 1 :(得分：0)
建议的想法可能会为查询创建一些性能问题（随着分区数量的增加）。一般来说，日期分区适用于几千个分区。
client_ids通常彼此无关，是散列的理想选择。虽然我们致力于支持更丰富的分区风格，但一种选择是将client_ids散列为N个桶（~100？），并具有N个分区表。这样，您可以在N个表中查询给定日期。例如，使用100个表会将成本降低到使用1个表和所有client_ids的成本的1％。它还应该扫描少量分区，从而也相应地提高性能。不幸的是，这种方法并没有解决将客户ID放在正确的表中的问题（必须由您管理）。