AWS Redshift列限制？

我一直在爲一個新的應用程序做一些AWS Redshift的負載測試，並且我注意到它每列的列限制爲1600。更糟糕的是，隨着列表中列的數量增加，查詢速度變慢。AWS Redshift列限制？

這裏沒有任何意義的是Redshift應該是一個列存儲數據庫，並且理論上不應該在特定的where子句中沒有選擇列的I/O命中。

更具體地說，當TableName是1600列時，我發現下面的查詢比如果TableName是1000列和相同的行數要慢很多。隨着列數的減少，性能提高。

SELECT COUNT(1) FROM TableName 
WHERE ColumnName LIKE '%foo%'

我的三個問題是：

這是怎麼回事？爲什麼Redshift聲稱自己是專賣店時有這個限制？
有關解決此限制的任何建議？多個小表的連接似乎最終接近單個表的性能。我還沒有嘗試過旋轉數據。
有沒有人有一個快速，實時的性能，水平可擴展列存儲數據庫的建議，沒有上述限制？我們所做的只是在大約10M（行）x 2500（列）數據限制的情況下對查詢進行計數。

來源

2015-09-03 mellocello

如果您需要超過1600列，則很有可能您的數據結構不完整。你應該尋找機會來規範你的數據*（正如你所說，在多個表中）*。列數的限制只是優化引擎的一個因素，它存儲的引用數量可能來自PostGreSQL的版本。列限制和列表是否完全無關。至於表現的下降，我以前從未見過。您的查詢是否如上所示？ – MatBailie

哦，如果你只處理10M x 2.5K，那麼你不應該需要RedShift。我會用PostGreSQL來做一些小事。我使用RedShift處理數十/數百個節點的數萬億行數據。 – MatBailie

@MatBailie，性能必須低於亞秒，這就是我們決定使用Redshift的原因。我非常肯定，一個列存儲數據庫的主要優點之一就是能夠在沒有與其他列關聯的情況下拉取任意列。你可以直接進入你需要的數據列，加載這些數據，就是這樣。你完全與其他專欄隔離。最後，不，我的數據結構良好。我從字面上有很多我想查詢的完全不相關的屬性。考慮一個細分用例。謝謝。 – mellocello

我無法準確解釋爲什麼它減慢了這麼多，但我可以驗證我們經歷了同樣的事情。

我認爲這個問題的一部分是Redshift每個節點每列至少存儲1MB。有很多列會產生大量的磁盤查找活動和I/O開銷。

1MB塊是有問題的，因爲大多數的，這將是空的空間，但它仍然會讀出光盤
有很多塊意味着列數據不會盡可能靠近在一起，紅移有做更多的工作來找到它們。

此外，（剛纔發生在我身上）我懷疑Redshift的MVCC控件會增加很多開銷。它試圖確保在執行查詢時獲得一致的讀取，並且可能需要記錄全部查詢中表的塊，甚至是不使用的列的塊。 Why is an implicit table lock being released prior to end of transaction in RedShift?

FWIW，我們列了幾乎所有BOOLEAN，我們已經通過壓縮它們（位掩碼）爲INT/BIGINTs並使用逐位函數訪問值有非常很好的效果。一個示例表從1400列（〜200GB）變爲〜60列（〜25GB），查詢時間提高了10倍以上（30-40下降到1-2秒）。

來源

2015-09-04 15:46:27

嗯。那麼有什麼想法什麼樣的數據庫更適合我的使用情況？水平可擴展的高可用性db和sub second count查詢，使用簡單的where子句針對大量屬性（3k）和大約10M行？ – mellocello

我們在嘗試解決此問題的同時評估了MemSQL。這是_insanely_快，但只在**第二**運行一個給定的查詢。第一次運行很慢，因爲它們使用GCC進行深度編譯。對於我們來說，因爲查詢是非常特殊的，所以最好留在Redshift中並使用按位功能。你也可以嘗試谷歌的BigQuery（我聽到很好的東西）。 –

AWS Redshift列限制？

回答

相關問題