Amazon Redshift 效能 - Amazon Redshift
大規模平行處理 單欄式資料儲存體 資料壓縮 查詢最佳化工具 結果快取 經過編譯的程式碼

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

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 連線通訊協定編譯不同的程式碼，因此使用不同通訊協定的兩個用戶端會分別產生編譯程式碼的第一次成本。使用相同通訊協定的用戶端，可從共用快取的程式碼而受惠。