AWS Redshift列限制？

Question

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

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

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

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

我的三個問題是：

1. 這是怎么回事？ 如果Redshift聲稱是一個專欄店，為什么會有這個限制？
2. 有關解決此限制的任何建議嗎？ 多個較小表的連接似乎最終接近單個表的性能。 我還沒有嘗試過旋轉數據。
3. 有沒有人建議快速，實時的性能，水平可擴展的列存儲數據庫沒有上述限制？ 我們所做的只是對大約10M（行）×2500（列）數據進行限制的簡單計數查詢。

Answer 1

我無法准確解釋為什么它減速太多但我能證實我們經歷過同樣的事情。

我認為部分問題是Redshift每個節點每列最少存儲1MB。 擁有大量列會產生大量磁盤搜索活動和I / O開銷。

• 1MB的塊是有問題的，因為大多數塊將是空的空間，但仍然會從磁盤讀取
• 擁有大量的塊意味着列數據不會位於一起，因此Redshift必須做更多工作才能找到它們。

此外，（剛剛發生在我身上）我懷疑Redshift的MVCC控件增加了很多開銷。 它會嘗試確保在查詢執行時獲得一致的讀取，並且可能需要記錄查詢中表的所有塊，甚至是未使用的列的塊。 為什么在RedShift中在事務結束之前釋放隱式表鎖？

FWIW，我們的列實際上都是BOOLEAN ，我們通過將它們（位掩碼）壓縮成INT / BIGINT並使用逐位函數訪問值得到了非常好的結果。 一個示例表從1400 cols（~200GB）到~60 cols（~25GB），查詢時間提高了10倍以上（30-40下降到1-2秒）。