Amazon Redshift - 查詢槽、並發和隊列之間的區別？
我們正在建構一個商業智能係統，我們有一個巨大的 PostgreSQL 數據庫 (DB) 用於進行所有資訊處理，還有一個 Redshift 數據倉庫 (DWH) 用於儲存數據並執行查詢。
後端是在 Java Server Faces (JSF) 中建構的，在此之前，查詢是線性的。有些視圖需要超過一分鐘才能完成查詢並將資訊載入到螢幕中，因此我們決定在 Java 中使用執行緒並使查詢非同步。
因此，我們為每個視圖準備了必要的查詢，以便從我們的 EC2 應用程序機器並行執行到我們的 Redshift DWH，並執行執行緒，但視圖仍然需要很長時間才能載入，有時甚至更長。
我們在文件中發現：
http://docs.aws.amazon.com/redshift/latest/dg/cm-c-executing-queries.html
http://docs.aws.amazon.com/redshift/latest/dg/c_troubleshooting_query_performance.html
http://docs.aws.amazon.com/redshift/latest/dg/r_wlm_query_slot_count.html
預設情況下，紅移會同時接收 5 個查詢，但這是我們可以更改的設置。
有 3 個主要的事情需要考慮：查詢槽、並發和隊列。我們已經明白了這一點：
隊列就像 Java 中的執行緒。一個查詢到達並被指定到“負載較少的”隊列，並等待輪到它解決。我們可以有盡可能多的隊列。隊列分配了一些記憶體（我們猜是平均分配的？）在隊列中，我們可以分配使用者組或查詢組。但在短期內，我們現在無法在查詢中進行大量分類工作。
並發是隊列可以並行執行的查詢量。預設為 5。
查詢槽是查詢可以使用的記憶體量。正如我們所理解的，它與並發有關。隊列的並發性越多，它擁有的每個查詢槽中的記憶體就越少。
我們嘗試了 3 個隊列，每個隊列有 5 個並發，但性能仍然很慢。
那麼，如果我們理解正確的話，有的views最多有25-28個query，總的載入時間在60s左右，那我們怎樣才能讓querys得到更快的解決呢？
我認為您對查詢隊列的理解有點偏離。
隊列就像 Java 中的執行緒。一個查詢到達並被指定到“負載較少的”隊列，並等待輪到它解決。
將查詢放在哪裡的決定與隊列的繁忙程度無關；查詢是根據您設置的規則分配的：http: //docs.aws.amazon.com/redshift/latest/dg/cm-c-wlm-queue-assignment-rules.html
我們可以有盡可能多的隊列。
不完全是，請查看http://docs.aws.amazon.com/redshift/latest/dg/cm-c-defining-query-queues.html。相關線路是
所有使用者定義隊列（不包括保留的超級使用者隊列）的最大總並發級別為 50。
所以並發肯定是有限的，但這是一個合理的限制，因為每個並發槽都會保留一些集群的資源。
一個隊列分配了一些記憶體（我們猜是平均分配的？）
預設情況下，記憶體在隊列之間平均分配，但您可以按集群記憶體的 1% 的粒度分配記憶體。請參閱上面有關定義查詢隊列的連結。
在隊列中，我們可以分配使用者組或查詢組。但在短期內，我們現在無法在查詢中進行大量分類工作。
創建使用者組和設置查詢組實際上非常簡單，請參閱http://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_GROUP.html和http://docs.aws.amazon.com/redshift/latest /dg/r_query_group.html。
如果您沒有設置使用者組或查詢組，那麼我的猜測是在添加額外隊列後您沒有看到任何改進，因為所有查詢仍然在單個查詢隊列中執行。（事實上，額外的隊列只會從執行查詢的隊列中獲取資源。）由於所有查詢都來自同一個使用者並且出於相同的目的，因此它們都應該解析到同一個查詢隊列是有道理的。更好的解決方案可能是只有一個隊列，但增加並發級別。（請記住，查詢隊列的資源在所有並發槽之間平均分配，即使它們沒有被使用，所以並發級別為 50 意味著沒有查詢獲得超過總資源的 2%。）
儘管如此，redshift 是一個比許多其他數據庫解決方案具有更高延遲的系統。如果您只想執行大量小查詢，那麼它可能不適合您的問題。
在我看來，您在 OLTP 模型中使用 Redshift，而不是作為 OLAP 引擎的最初目的。
從您上面的問題中，我可以發現兩個工作負載（或“擔憂”）：
- 數據從 Postgres 載入到集群中
- 查詢 Redshift 集群中的數據
您似乎沒有在 Redshift 中執行任何轉換，即，一旦您將數據載入到集群中，數據將保持原樣，您不再對其進行操作。
如果您想要更快的查詢，我認為您需要考慮三件事：
- 將您的關注點分成兩個不同的模式。一個用於您的原始數據載入，一個用於您的臨時查詢。如果您的使用者在載入數據時查詢相同的表，您將遇到表鎖。
- 設置工作負載管理，以便將負載與臨時查詢分開。這樣，您可以為每個隊列分配正確的記憶體量和並發性。否則，您將使用插槽過度配置集群，並且您的查詢將缺乏記憶體，回退到磁碟，從而減慢整個集群的速度。
- 與其直接查詢您的集群，不如考慮使用帶有 Amazon RDS 和 dblink 的記憶體層。這樣您就可以在 OLTP 模型中使用 Redshift。請參閱我們的文章“你有 Postgres 蛋糕並且也吃它嗎”。您將看到更快的查詢。
我寫了一篇關於我們如何配置 Redshift 以提高性能的詳細文章，並附有一張能說明一千個單詞的圖片。
