Redshift
在 Redshift 中使用時間戳作為 DISTKEY 是否合適?
我在理解如何為我正在處理的表中選擇 DISTKEY 時遇到了一些麻煩。
考慮下表:
create table test_table ( country char(2) encode zstd, record_time bigint encode zstd not null, ip bigint encode zstd, identifier varchar(41) encode zstd not null, lat numeric(10,3) encode zstd, long numeric(10,3) encode zstd, PRIMARY KEY (event_time, hash) ) DISTKEY(event_time) SORTKEY(country, event_time, hash)
我的理解是,僅當要與其他表連接時,DISTKEY 才真正重要。
該表將是其集群中唯一的一個,因此不會與其他表連接。既然是這種情況,我是否正確地假設 DISTKEY 是不必要的/冗餘的,或者 DISTKEY 的影響超出了眼睛的範圍?
這是非常極端的情況,但在某些情況下,數據位置的重要性並不大。
假設您要求數據庫執行此查詢:
SELECT COUNT(DISTINCT ip) FROM test_table GROUP BY country
如果表格按國家/地區分佈,則不需要網路活動(我對此進行了測試以確認)。對於任何其他分發方式,雜湊表在邏輯上需要通過網路重新分發(我也對此進行了測試以確認)。
也就是說,您可能只想選擇 EVEN 分佈樣式以最大限度地提高掃描速度。就此而言,也許您想在這個案例中使用 Spectrum。
您應該考慮基於 1) 獲得數據的均勻分佈和 2) 在將要連接的表上使用相同的 distkey 的 distkey,以便可以在本地進行連接
如果您使用時間戳 (record_time) 作為 dist 鍵,那麼如果您的數據具有重要的時間跨度(例如一年或更長時間),那麼這對於選擇時間戳子集(例如前一周或前一個月的數據)的查詢將非常糟糕。
我建議您仔細閱讀 http://docs.aws.amazon.com/redshift/latest/dg/c_designing-tables-best-practices.html