红移时间序列表加载问题

Question

红移文档将时间序列表确定为最佳实践：best-practices-time-series-tables.html

但是，它没有解决以下任何问题：

• 一个联合视图中有多少个表--所有视图都是合理的--数百个？(未回答的)
• 任何向联合写入的方法-所有视图和红移将这些插入直接指向正确的底层表？(回答:否)
• 加载底层表的最有效方法？也许使用消防软管插入到一个暂存表中，然后定期地将这些行插入到联合所有视图中的适当表中(未回答的)
• 在查询联合-所有视图时，如果它们的日期范围超出了查询的条件，那么是否可以启用红移以消除一些底层分区(表)？(回答:否)
• redshift是否支持删除旧表、添加新表和在事务中重建union-all视图？(unanswered)

我的处境：

• 每天增加1亿行，3年后将增加到5亿行
• 12个月保留期
• 估计99%的查询将在最近的1-7天内进行。
• 数据是通过运动消防软管写入现有的表到s3，然后触发一个副本到红移表。

我提出的解决办法：

• 创建一个包含union视图的年度日表，以及一个dist_key of sensor_id (100,000+ uniq值)和一个sort_key of (时间戳，sensor_id)。
• 把消防水管装载到舞台上
• 创建单独的进程，每小时查询一次暂存表，以发现表中的数据日期，然后对“适当表”执行insert select * where timestamp = table的时间戳。
• 此逐时写入器可能会将表重命名、多个insert-selects和表重新创建在事务中，使其在消防管道中不可见。
• 每月一次删除旧表，创建下一个月的表，并重新生成视图。
• 这种联合-所有的视图维护可能被包装在一个事务中，以避免对用户的影响。
• 每晚运行一次真空分析仪。

编辑:添加说明哪些问题已经得到解决，并在建议的解决方案中添加了一些细节。

Answer 1

你的提议过程听起来不错！虽然我不能回答你所有的问题，但以下是一些信息：

任何将所有视图写入联合视图并进行红移的方法都可以将这些插入指向正确的底层表？

视图是只读的。不可能将数据写入视图，也不可能在预期Redshift将其发送到适当的表时插入数据(例如，给定一天的特定表)。

如果联合所有视图的日期范围超出了查询的条件，那么是否允许红移以消除一些底层分区(表)？

Redshift不会从查询中排除特定的表，但是它将避免通过使用区域映射读取特定的磁盘块。写入磁盘的每一个数据块都与特定的表和列相关联。块具有区域映射，它指示存储在块中的该字段的最小值和最大值。

如果查询包含WHERE子句，Redshift可以跳过不包含相关数据的块。这在SORTKEY列上使用时特别强大，因为类似的数据范围是分组在一起的。

考虑到使用日期作为SORTKEY，如果查询包含基于该列的WHERE子句，Redshift将读取很少的磁盘块。这与跳过表的想法非常相似，但实际上它跳过读取磁盘块。