紅移時間序列表加載問題

Question

紅移文檔識別時間序列表作爲最佳實踐： http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-time-series-tables.html

但是，它並沒有解決任何的下列問題：

• 多少桌在工會內部 - 所有觀點都是合理的 - 數百？ （無法解答）
• 任何寫入union-all視圖並使用redshift將任何方法寫入正確的基礎表的方法？ （答案：否）
• 加載底層表的最有效方法是什麼？也許使用firehose插入登臺表，然後定期將這些行插入union-all視圖內的適當表中？ （無法回答）
• 任何方式來啓用紅移消除一些底層分區（表）時查詢union-all視圖，如果他們的日期範圍是在查詢的標準之外？ （答案爲否）
• 可以支持紅移支持刪除舊錶，添加新表以及在事務內重建union-all視圖？ （懸而未決）

我的情況：

• 億行每天新增，這將增長到了500萬在3年內
• 12個月保留所需
• 估計所有的99％查詢將觸及最近1-7天
• 數據通過kinesis firehose寫入到現有表中，然後s3觸發副本到紅移表。

我提出的解決方案：

• 創建年的日表與UNION ALL視圖，與sensor_id的dist_key（100,000 uniq的值）和（時間戳，sensor_id）一sort_key一起。
• 有流水加載到臨時表
• 創建獨立的過程，一次一個小時的查詢臨時表來表中發現數據的日期，然後執行插入「適當的表」選擇從那裏戳=表的時間戳*。
• 此小時寫入程序可能會包含表重命名，多重插入選擇和表在事務中重新創建以便不可見。
• 每月一次刪除舊錶，創建表的下個月和重建視圖。
• 這種union-all視圖維護可能可能被封裝在一個事務中以避免對用戶產生影響。
• 一旦夜間運行真空分析儀。

EDITS：增加的筆記，用於識別哪些問題已被回答，併爲建議的解決方案添加了一些細節。

Answer 1

您提議的流程聽起來相當不錯！儘管我無法回答所有問題，但以下是一些信息：

任何寫入union-all視圖並使用redshift將任何插入指向正確的基礎表的方法？

該視圖是隻讀的。無法寫入視圖，也不可能在預計Redshift將數據發送到適當的表（例如給定日期的特定表）時插入數據。

如果日期範圍超出查詢條件時查詢union-all視圖，可以使用紅移消除某些底層分區（表）的任何方式？

紅移將不會從查詢中排除特定的表，但它會避免通過使用區地圖閱讀特定的磁盤塊。寫入磁盤的每個數據塊都與特定的表和列相關聯。該塊有一個區域圖，表示該區域內存儲的該區域的最小值和最大值。

如果查詢包含WHERE子句，Redshift可以跳過不包含相關數據的塊。在SORTKEY列上使用時，此功能特別強大，因爲類似範圍的數據組合在一起。

鑑於您使用的日期爲SORTKEY，如果查詢包含基於該列的WHERE子句，則Redshift將讀取極少數磁盤塊。這與跳過表的想法非常相似，但實際上它會跳過讀取磁盤塊。