Redshift和超寬表

爲了處理多租戶維DW中特定對象的自定義字段，我創建了Redshift不太喜歡的超寬非規格化維表（列的數百列，硬編碼限制）;）。Redshift和超寬表

USER1 | attR1位|上的記錄屈指可數單列attR2位... attr500

即使是無辜的更新查詢需要大約20秒。（這是令人驚訝的，因爲我猜想它不應該是柱狀數據庫上的這樣的問題。）

任何指針如何修改設計以更好地從規範化源表報告（一個用戶具有多個不同的屬性，一個屬性是一行）去非規範化（每個用戶有一行，通用列，每個租戶都不同）？

或者任何人試圖在Redshift中執行標準化記錄的轉置（旋轉）爲非規格化視圖（表格）？我擔心表演。

2016-11-22 Dolfa

請您澄清一下 - 你是說SELECT性能很差，或者只是更新性能？（Redshift針對查詢進行了優化，而不是用於更新。）表中有多少行，以及有多少行正在更新？你在桌上使用SORTKEY和DISTKEY嗎？你能否提供你的問題樣本來展示你的情況？謝謝。 –

表格很小（舞臺表），可以說幾十/幾百條記錄，但可以記錄數百列。查詢會像這樣：_update stage set validFrom = sysdate，validTo = 2999-01-01_。 Planner告訴我它正在做'順序掃描'。 – Dolfa

可能很重要的想法如何 Redshift存儲數據，然後實現該數據的更新。

每一列都存儲在它自己的1MB塊序列中，這些塊的內容由SORTKEY決定。因此，排序鍵值的多少行可以適合1MB，那麼對於其他所有列，相應的1MB中有多少（和哪些）值是對應的1MB。其變化不只是塊（S） -

當你問到紅移一個UPDATE排它實際上是對應於該行所有列寫入整個區塊的新版本。如果您有1,600列，這意味着更新單個行需要Redshift將至少1,600MB的新數據寫入最低。

如果更新觸及許多不在一起的行，則可能會放大此問題。我強烈建議選擇SORTKEY，它與正在更新的數據範圍密切對應，以最大限度地減少寫入量。

2016-12-06 18:27:12

我想知道Redshift是否只觸摸修改過的列（如我所料），或者需要刪除並向所有列插入新記錄（如您所述）。看來以後是真的，你是對的（這有點令人驚訝，但我不知道柱狀數據庫的內部知道如此深，理解它爲什麼這樣做。每天學習新的東西:)） – Dolfa

我相信它必須與他們使用的MVCC交易方法。通過殺死新塊並從先前塊中刪除墓碑來回滾更改。我想你可以用單列塊來完成這項工作，但是你需要跟蹤每列的時代而不是每個表格。 –

Redshift中超寬桌面需要注意的另一件事是他們吃了瘋狂的磁盤空間。我們製作的實例：3600行，1600列，S3中44KB壓縮，Redshift中128GB。 –

回答