Amazon Aurora MySQL 的平行查詢 - Amazon Aurora
平行查詢的概觀

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

Amazon Aurora MySQL 的平行查詢

此主題說明 Amazon Aurora MySQL 相容版本的平行查詢效能最佳化。此功能使用特定資料密集查詢的特殊處理路徑，同時善用 Aurora 共用儲存架構。平行查詢最適用於其資料表具有數百萬資料列的 Aurora MySQL 資料庫叢集，以及需要數分鐘或數小時來完成的分析查詢。

主題

Aurora MySQL 平行查詢的概觀

Aurora MySQL 平行查詢是一種最佳化操作，它可以將處理資料密集查詢時牽涉到的一些輸入/輸出和運算平行化。平行化的工作包括從儲存體擷取資料列、擷取資料行值，以及判斷哪些資料列符合 WHERE 子句和 join 子句中的條件。這類資料密集的工作會被委派 (資料庫最佳化術語叫做下推) 給 Aurora 分散式儲存層中的多個節點。少了平行查詢，每個查詢會將所有掃描到的資料帶到 Aurora MySQL 叢集 (前端節點) 中的單一節點，然後在那裡執行所有的查詢處理。

提示

PostgreSQL 資料庫引擎也有一個功能稱為「平行查詢」。該功能與 Aurora 平行查詢無關。

開啟平行查詢功能時，Aurora MySQL 引擎會自動判斷查詢何時可以受益，而不需要如提示或表格屬性之類的 SQL 變更。下列各節說明平行查詢何時適用於查詢。您也可以了解如何確保將平行查詢應用至效益最高之處。

注意

平行查詢最佳化可為需要幾分鐘或幾小時才能完成的長時間執行的查詢提供最大效益。Aurora MySQL 通常不會對廉價查詢最佳化平行查詢。如果另一種最佳化技術更有意義，例如查詢快取、緩衝集區快取或索引查詢，則通常不會執行平行查詢最佳化。如果發現系統未如您預期般使用平行查詢，請參閱 確認哪些陳述式使用平行查詢。

優勢

使用平行查詢，您可以在 Aurora MySQL 資料表上執行資料密集的分析查詢。在很多情況下，與傳統的查詢處理分工相比，可以獲得數量級的效能提升。

平行查詢的優點如下：

  • 提升輸入/輸出效能，原因是可跨多個儲存節點將實體讀取請求平行化。

  • 減少網路流量。Aurora 不會將整個資料頁面從儲存節點傳輸至前端節點，然後篩選掉不需要的資料列和資料欄。反之，Aurora 會傳輸精簡的 Tuple，其中僅包含結果集所需的資料欄值。

  • 減少前端節點上的 CPU 使用量，原因是下推 WHERE 子句的函數處理，資料列篩選和資料欄投影。

  • 減少緩衝集區的記憶體壓力。平行查詢處理的網頁不會新增至緩衝集區。此方法可減少資料密集型掃描從緩衝集區中收回常用資料的機會。

  • 潛在減少擷取轉換負載 (ETL) 管線中的資料複製，方法為使得在現有資料上執行長時間執行的分析查詢變成可行。

架構

平行查詢功能使用 Aurora MySQL 的主要架構原理：將資料庫引擎與儲存子系統分離，以及簡化通訊協定來減少網路流量。Aurora MySQL 使用這些技術來加速寫入密集操作，例如重做日誌處理。平行查詢可將相同原理套用至讀取操作。

注意

Aurora MySQL 平行查詢的架構不同於其他資料庫系統中名稱相似功能的架構。Aurora MySQL 平行查詢不涉及對稱式多工處理 (SMP)，因此不依賴資料庫伺服器的 CPU 容量。平行處理發生於儲存層，與充當查詢協調器的 Aurora MySQL 伺服器無關。

依預設，若沒有平行查詢，Aurora 查詢的處理會涉及將原始資料傳輸至 Aurora 叢集內的單一節點 (前端節點)。接著 Aurora 會在該單一節點上的單一執行緒中，針對該查詢執行所有進一步處理。使用平行查詢時，這類輸入/輸出密集的工作大部分會被委派給儲存層中的節點。只有結果集的精簡資料列會傳回到前端節點，而已篩選的資料列，以及已擷取和轉換的資料欄值也會一起傳回。效能優點來自網路流量減少、前端節點上 CPU 使用量減少，以及跨儲存節點將輸入/輸出平行化。平行輸入/輸出、篩選和投影的數量與執行查詢之 Aurora 叢集中的資料庫執行個體數量無關。

先決條件

使用並行查詢的所有功能需要執行 2.09 或更新版本的 Aurora MySQL 資料庫叢集。如果您已經有要與平行查詢搭配使用的叢集，您可以將其升級為相容版本，並在之後開啟平行查詢。在這種情況下，請務必遵循 平行查詢的升級考量 中的升級程序，因為這些較新版本中的組態設定名稱和預設值不同。

叢集中的資料庫執行個體必須使用 db.r* 執行個體類別。

請確定您的叢集已開啟雜湊聯結最佳化。若要瞭解如何操作，請參閱開啟平行查詢叢集的雜湊聯結。

若要自訂參數 (例如 aurora_parallel_query 和) aurora_disable_hash_join，您必須擁有與叢集搭配使用的自訂參數群組。您可以使用資料庫參數群組，為每個資料庫執行個體個別指定這些參數。不過，我們建議您在資料庫叢集參數群組中指定它們。如此一來，叢集中的所有資料庫執行個體都會繼承這些參數的相同設定。

限制

下列限制適用於平行查詢功能：

  • Aurora I/O-Optimized 資料庫叢集儲存組態不支援平行查詢。

  • 您不能將平行查詢與 db.t2 或 db.t3 執行個體類別一起使用。即使您使用 aurora_pq_force 工作階段變數要求平行查詢，此限制也適用。

  • 平行查詢不適用於使用 COMPRESSED 或 REDUNDANT 資料列格式的資料表。針對您計劃搭配平行查詢使用的資料表，請使用 COMPACT 或 DYNAMIC 資料列格式。

  • Aurora 會使用成本型演算法來判斷是否要針對每個 SQL 陳述式使用平行查詢機制。在陳述式中使用某些 SQL 建構可以防止平行查詢，或使該陳述式不太可能進行平行查詢。如需 SQL 建構與平行查詢相容性的相關資訊，請參閱 Aurora MySQL 中平行查詢的 SQL 建構。

  • 每個 Aurora 資料庫執行個體一次只能執行特定數目的平行查詢工作階段。如果一個查詢具有多個使用平行查詢的部分，例如子查詢、聯結或 UNION 運算子，則這些階段會依序執行。任何時候陳述式只會視為單一平行查詢工作階段。您可以使用平行查詢狀態變數，監控作用中工作階段的數目。您可以查詢狀態變數 Aurora_pq_max_concurrent_requests，檢查指定之資料庫執行個體的並行工作階段限制。

  • 平行查詢可用於 Aurora 支援的所有 AWS 區域。對於大多數 AWS 區域，使用平行查詢的 Aurora MySQL 最低要求版本為 2.09。

  • 平行查詢是為了改善資料密集型查詢的效能而設計。並非為輕量級查詢而設計。

  • 建議您針對 SELECT 陳述式使用讀取器節點，尤其是資料密集型陳述式。

平行查詢的 I/O 成本

如果您的 Aurora MySQL 叢集使用平行查詢，您可能會看到 VolumeReadIOPS 值增加。平行查詢不會使用緩衝集區。因此，雖然查詢速度很快，但這種最佳化處理可能會導致讀取操作和相關費用增加。

您查詢的平行查詢 I/O 成本是在儲存層進行計量，並且在平行查詢開啟的情況下相同或更大。您得到的好處是查詢效能的改善。使用平行查詢可能會導致 I/O 成本較高的原因有兩個：

  • 即使資料表中的某些資料位於緩衝集區中，平行查詢仍需要在儲存層掃描所有資料，因而產生 I/O 成本。

  • 執行平行查詢不會對緩衝集區進行暖機。因此，連續執行相同的平行查詢會產生完整的 I/O 成本。