Amazon Redshift 效能

本主題說明驅動效能的 Amazon Redshift 元件。了解這些元件將協助您調校效能，並使用 Amazon Redshift 疑難排解效能不佳的問題。

Amazon Redshift 運用這些效能功能，實現超快速的查詢執行。

大規模平行處理

大規模平行處理 (MPP) 作業讓處理大量資料的最複雜查詢，也能快速地執行。多重運算節點進行所有查詢處理作業，最後再將結果彙總 (每個節點的核心會針對整個資料的一部分，執行相同的編譯後查詢片段)。

Amazon Redshift 會將資料表的列分發給運算節點，以平行處理資料。透過為每個資料表選擇適合的分佈索引鍵，您可以將資料的分發最佳化，進而平衡工作負載，並且將資料在節點之間的移動次數減到最少。如需詳細資訊，請參閱選擇最佳的分佈方式。

從一般檔案載入資料，可透過將工作負載分散到多個節點，一邊同時從多個檔案讀取，來發揮平行處理的效益。如需如何將資料載入資料表的相關資訊，請參閱載入資料的 Amazon Redshift 最佳實務。

單欄式資料儲存體

資料庫資料表的單欄式儲存方式，大幅地降低了整體磁碟輸入/輸出需求，成為實現最佳化分析查詢效能的重要因素。如需詳細資訊，請參閱單欄式儲存。

以適當地方式將欄排序時，查詢處理器就能夠快速地篩選掉龐大的資料區塊子集。如需詳細資訊，請參閱選擇最佳的排序索引鍵。

資料壓縮

資料壓縮可降低對儲存空間的需求，進而減少磁碟輸入/輸出，提升查詢作業的效能。執行查詢作業時，會將壓縮的資料讀入記憶體，然後在進行查詢時將資料解壓縮。載入記憶體的資料量減少，即可讓 Amazon Redshift 配置更多的記憶體來分析資料。由於單欄式儲存會依順序儲存類似的資料，Amazon Redshift 就能夠採用與單欄式資料類型特別相關的適應性壓縮編碼機制。對資料表欄進行資料壓縮的最佳方式，就是在載入資料表和資料時，讓 Amazon Redshift 套用最佳化的壓縮編碼機制。如要進一步了解自動資料壓縮，請參閱利用自動壓縮載入資料表。

查詢最佳化工具

Amazon Redshift 查詢執行引擎採用支援 MPP 的查詢最佳化工具，也運用了欄式導向的資料儲存體。Amazon Redshift 查詢最佳化工具建置了重大的增強與擴充功能，可用來處理複雜的分析查詢作業，這類查詢經常包含多重資料表的合併、子查詢和彙總操作。若要進一步了解如何將查詢作業最佳化，請參閱查詢效能調校。

結果快取

為了縮短查詢執行期並改善系統效能，Amazon Redshift 會將特定查詢類型的結果快取在領導者節點的記憶體中。當使用者提交查詢時，Amazon Redshift 會針對結果快取，檢查是否建立了查詢結果的有效快取副本。如果在結果快取中找到符合者，Amazon Redshift 會使用快取的結果，不會執行查詢。使用者並不會察覺到結果快取作業的進行。

結果快取預設為開啟。若要關閉目前工作階段的結果快取作業，請將 enable_result_cache_for_session 參數設定為 off。

當下列所有情況都符合時，Amazon Redshift 會使用新查詢的快取結果：

• 提交查詢的使用者，對查詢中所使用的物件具有存取許可。

• 查詢中的資料表或檢視尚未經過修改。

• 查詢並未使用每次執行時都必須求值的函式，例如 GETDATE。

• 查詢並未參考 Amazon Redshift Spectrum 外部資料表。

• 可能影響查詢結果的組態參數不變。

• 查詢在語法上符合快取的查詢。

為了最大限度地提高快取效率並有效利用資源，Amazon Redshift 不會快取某些大型查詢結果集。Amazon Redshift 會根據許多因素判斷是否要快取查詢結果。這些因素包括快取中的項目數量，以及 Amazon Redshift 叢集的執行個體類型。

若要判斷查詢作業是否使用了結果快取，請查詢 SVL_QLOG 系統畫面。如果查詢使用了結果快取，source_query 欄會傳回來源查詢的查詢 ID。如果未使用結果快取，source_query 欄的值為 NULL。

下列範例顯示，由 userid 104 和 userid 102 所提交的查詢，使用了 userid 100 所執行查詢的結果快取。

select userid, query, elapsed, source_query from svl_qlog 
where userid > 1
order by query desc;

userid | query  | elapsed  | source_query
-------+--------+----------+-------------
   104 | 629035 |       27 |       628919
   104 | 629034 |       60 |       628900
   104 | 629033 |       23 |       628891
   102 | 629017 |  1229393 |             
   102 | 628942 |       28 |       628919
   102 | 628941 |       57 |       628900
   102 | 628940 |       26 |       628891
   100 | 628919 | 84295686 |             
   100 | 628900 | 87015637 |             
   100 | 628891 | 58808694 |             

經過編譯的程式碼

領導節點會將經過完整最佳化編譯的程式碼，分發給叢集的所有節點。編譯查詢可省去與直譯器相關的資源耗用，進而提升執行期速度，尤其是複雜的查詢作業。編譯後的程式碼會經過快取，並在同一個叢集上的工作階段之間共用。因此，未來執行相同查詢的速度會更快，即使使用不同的參數也應是如此。

查詢執行引擎會針對 JDBC 和 ODBC 連線通訊協定編譯不同的程式碼，如此，使用不同通訊協定的兩個用戶端，各會產生編譯程式碼的首次成本。使用相同通訊協定的用戶端，可從共用快取的程式碼而受惠。