效能 - Amazon Redshift

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

效能

Amazon Redshift 會使用這些性能功能,實現超快速的查詢執行作業。

大規模平行處理

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

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

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

單欄式資料儲存體

資料庫資料表的單欄式儲存方式,大幅地降低了整體磁碟輸入/輸出需求,成為實現最佳化分析查詢效能的重要因素。以單欄式儲存資料庫資料表的資訊,可減少磁碟輸入/輸出要求的數量,和需要從磁碟載入的資料量。載入記憶體的資料量減少,Amazon Redshift 可讓 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 與 psql (libq) 連線通訊協定,分別編譯不同的程式碼,如此,使用不同通訊協定的兩個用戶端,各會產生編譯程式碼的首次成本。不過,使用相同通訊協定的其他用戶端,將可受惠於共用快取的程式碼。