Redshift更新使用序列掃描非常緩慢

我必須更新大表（600米行）中的約300行，我試圖使其更快。Redshift更新使用序列掃描非常緩慢

我使用的查詢是有點棘手：

UPDATE my_table 
SET name = CASE WHEN (event_name in ('event_1', 'event_2', 'event_3')) 
THEN 'deleted' ELSE name END 
WHERE uid IN ('id_1', 'id_2')

我嘗試使用EXPLAIN在此查詢和獲取：

XN Seq Scan on my_table (cost=0.00..103935.76 rows=4326 width=9838) 
    Filter: (((uid)::text = 'id_1'::text) OR ((uid)::text = 'id_2'::text))

我有一個交錯的排序關鍵字，並且uid是一個包括在這個sortkey中的列。爲什麼查詢看起來像這樣的原因是，在真實的上下文中SET的列數（以及名稱）可能會有所不同，但它可能不會超過10個。基本思想是我不想要交叉連接（更新規則是特定於列的，我不想將它們混合在一起）。例如，在將來會有一個查詢，如：

UPDATE my_table 
SET name = CASE WHEN (event_name in ("event_1", "event_2", "event_3")) THEN 'deleted' ELSE name END, 
address = CASE WHEN (event_name in ("event_1", "event_4")) THEN 'deleted' ELSE address END 
WHERE uid IN ("id_1", "id_2")

不管怎樣，回到第一個查詢，它運行了很長一段時間（約45分鐘），並採取100％的CPU。

我試圖檢查更簡單查詢：

explain UPDATE my_table SET name = 'deleted' WHERE uid IN ('id_1', 'id_2') 
XN Seq Scan on my_table (cost=0.00..103816.80 rows=4326 width=9821) 
    Filter: (((uid)::text = 'id_1'::text) OR ((uid)::text = 'id_2'::text))

我不知道還有什麼我可以添加到這個問題，使其更清晰，會很樂意聽到任何意見。

來源

2017-02-21 Dmitry Smirnov

由於CASE語句中的WHERE關鍵字會導致錯誤，所以您的實際查詢必須相當不同。那裏有一個子選擇嗎？另外，桌子上有什麼？ – systemjack

啊，確實現在糾正了它。 –

您的查詢對我而言看起來不錯。我自己並沒有很好的交錯排序鍵。在不屬於排序關鍵字的列上進行過濾使用複合排序關鍵字與交錯關鍵字，我仍然獲得了10倍左右的改進。在sortkey列上過濾應該會更好。我們放棄了使用交錯密鑰，直到Redshift將它們整理出來。 – systemjack

您是否嘗試刪除交叉排序鍵，並使用uid上的簡單排序鍵或uid作爲第一列來替換它？

此外，名稱uid使我認爲您可能正在使用GUID/UUID作爲值。我建議這是一個反模式對於Redshift中的id值，特別是對於排序鍵。

問題與GUID/UUID id：

不會出現在可預見的序列
- 往往會引發一個完整的順序掃描
- 新行總是打亂排序
壓縮很差
- 需要用於存儲更多的磁盤空間
- 需要更多數據要讀取查詢在紅移

來源

2017-02-21 19:38:02

是的，uid是MongoId字符串。只是意識到sortkey至少很可能不起作用，因爲在600mil行中只有幾百萬行被排序。這可能需要提出另一個問題，但是也許你可以提出一些建議：如果一張表太大以致吸塵時間過長，並且深層複製需要更多的磁盤空間而不是可用，那麼可以通過另一種方法重新索引表格？ –

這取決於表格有多大TBH。有了一個真正巨大的桌子，你可以把它分成包含一個有限的數據集（例如一個星期或一個月）和一個'UNION ALL'的更小的表格，以替換原始表格。你沒有提到你的'DISTSTYLE' - 我會嘗試使用'uid'作爲時間戳列上排序鍵的分配鍵。 –

如果您沒有空間，可以對S3執行增量式卸載，請刪除您卸載的範圍，然後從S3複製到新表格。另外，如果您有空間問題並且尚未啓用壓縮，那麼這將是一個很好的機會：http://docs.aws.amazon.com/redshift/latest/dg/t_Compressing_data_on_disk.html。 – systemjack

更新刪除，然後插入時。按設計紅移只需將行標記爲已刪除，而不是物理刪除它們（幻影行）。明確真空只刪除< table_name>需要回收空間。

Seq。掃描受到這些鬼行影響。建議在命令之上運行並稍後檢查查詢的性能。

來源

2017-04-08 23:27:55 Ravi

Redshift更新使用序列掃描非常緩慢

回答

相關問題