在Redshift中創建大型VARCHAR值有缺點嗎？

源數據保持爲持續變得越來越大的字段投擲值。現在我正在使用VARCHAR（200），但我可能會去VARCHAR(400)。使用大數字有什麼不利嗎？在Redshift中創建大型VARCHAR值有缺點嗎？

來源

2015-05-14 simplycoding

你是什麼意思「下行」？如果不使列的大小足夠大，那麼存在一個非常大的缺點 - 您無法使用它來存儲要在其中存儲的值。

至於額外的開銷，你不必擔心。一個varchar()類型基本上只佔用該值所需的存儲空間，另外還有一個小長度的開銷。另外，「400」不是那麼大的數字，特別是與「200」相比時。

因此，如果您需要400個字節來存儲該值，請更改表以存儲它。改變值的長度可能會有開銷。我不確定RedShift是否會因爲類型改變而感到需要複製數據。但是，對性能的影響應該可以忽略不計。

來源

2015-05-15 01:10:23

我只是假設，以爲會有額外的開銷來分配的空間變化量爲字段 – simplycoding

不要爲了方便而使用最大列大小。

取而代之的是，考慮一下您可能存儲在VARCHAR列中的最大值，並相應地調整列的大小。由於Amazon Redshift非常有效地壓縮列數據，因此創建比所需大得多的列對數據表大小的影響最小。但是，在處理複雜查詢期間，中間查詢結果可能需要存儲在臨時表中。由於臨時表未進行壓縮，因此不必要的大型列會佔用過多的內存和臨時磁盤空間，這會影響查詢性能。

http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-smallest-column-size.html

來源

2015-05-19 07:59:45

。。該文檔沒有意義。 'VARCHAR（）'僅爲正在存儲的值使用空間，外加固定的少量開銷（http://docs.aws.amazon.com/redshift/latest/dg/r_Character_types.html）。無論值是否未壓縮，RedShift都不應該將填充的varchar值長於實際長度。 –

那麼這些文檔是由數據庫維護人員編寫的，所以我想這是有原因的。更重要的是，我已經測試過它，它有助於改善。如果我不得不猜測，我懷疑在查詢處理時，當列被「重新實現」爲行時，數據庫會爲潛在的巨大列分配額外的RAM。 –

在Redshift中創建大型VARCHAR值有缺點嗎？

回答

相關問題