View a markdown version of this page

效能效率支柱 - AWS 方案指引
了解圖形建模最佳化查詢適當大小的叢集最佳化寫入

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

效能效率支柱

AWS Well-Architected Framework 的效能效率支柱著重於如何在擷取或查詢資料時最佳化效能。效能最佳化是下列的增量和持續程序：

  • 確認業務需求

  • 測量工作負載效能

  • 識別效能不佳的元件

  • 調校元件以符合您的業務需求

效能效率支柱提供使用案例特定的指導方針，可協助識別正確的圖形資料模型和要使用的查詢語言。它還包括從 Amazon Neptune 擷取資料和取用資料的最佳實務。

效能效率支柱著重於下列關鍵領域：

  • 圖形建模

  • 查詢最佳化

  • 叢集大小適中

  • 寫入最佳化

了解圖形建模

了解已標記屬性圖 (LPG) 與資源描述架構 (RDF) 模型之間的差異。在大多數情況下，這是偏好事項。不過，有幾個使用案例，其中一個模型比另一個模型更適合。如果您需要了解連接圖形中兩個節點的路徑，請選擇 LPG。如果您想要跨 Neptune 叢集或其他圖形三元存放區聯合資料，請選擇 RDF。

如果您要建置軟體即服務 (SaaS) 應用程式或需要多租用戶的應用程式，請考慮在資料模型中整合租用戶的邏輯分離，而不是每個叢集有一個租用戶。若要實現該類型的設計，您可以使用名為 SPARQL 的圖形和標籤策略，例如在標籤前面加上客戶識別符，或新增代表租用戶識別符的屬性鍵/值對。請確定您的用戶端層注入這些值，以保持該邏輯分隔。如需多租用建議的詳細資訊，請參閱執行 Amazon Neptune 資料庫ISVs 的多租用指引。

查詢的效能取決於處理查詢時需要評估的圖形物件數量 （節點、邊緣、屬性）。因此，圖形模型可能會對應用程式的效能產生重大影響。盡可能使用精細標籤，並僅存放實現路徑確定或篩選所需的屬性。若要達到更高的效能，請考慮預先計算圖形的部分，例如建立摘要節點或連接常見路徑的更多直接邊緣。

嘗試避免在具有異常大量邊緣且具有相同標籤的節點之間導覽。這類節點通常有數千個邊緣 （其中大多數節點的邊緣計數為十）。結果是運算和資料複雜性更高。這些節點在某些查詢模式中可能不會有問題，但建議您以不同的方式建立資料模型，以避免這種情況，尤其是如果您將導覽到節點做為中繼步驟時。您可以使用慢查詢日誌來協助識別瀏覽這些節點的查詢。您可能會觀察到比平均查詢模式高出許多的延遲和資料存取指標，特別是如果您使用偵錯模式時。

如果您的使用案例支援節點和邊緣，請使用決定性節點 IDs，而不是使用 Neptune 為 IDs 指派隨機 GUID 值。依 ID 存取節點是最有效率的方法。

最佳化查詢

openCypher 和 Gremlin 語言可以交替用於 LPG 模型。如果效能是首要考量，請考慮交替使用兩種語言，因為對於特定查詢模式，一種可能比另一種更好。

Neptune 正在轉換為其替代查詢引擎 (DFE)。openCypher 僅在 DFE 上執行，但 Gremlin 和 SPARQL 查詢都可以選擇使用查詢註釋在 DFE 上執行。考慮在啟用 DFE 的情況下測試查詢，並在不使用 DFE 時比較查詢模式的效能。

Neptune 已針對從單一節點或一組節點開始的交易類型查詢進行最佳化，並從那裡散出，而不是評估整個圖形的分析查詢。對於分析查詢工作負載，請使用 Neptune Analytics。Neptune Analytics 是調查、探索性或資料科學工作負載的理想選擇，這些工作負載需要快速迭代以進行資料、分析和演算法處理。它也可以對圖形資料執行向量搜尋，並直接從 Neptune 資料庫執行個體載入資料。如果 Neptune Analytics 不符合您的需求，您也可以考慮AWS 適用於 Pandas 的 SDK，或使用 neptune-export 結合 AWS Glue或 Amazon EMR。

若要識別模型和查詢中的效率低下和瓶頸，請針對每種查詢語言使用 profile和 explain API，以取得查詢計劃和查詢指標的詳細說明。 APIs 如需詳細資訊，請參閱 Gremlin 描述檔、openCypher explain 和 SPARQL explain。

了解您的查詢模式。如果圖形中的不同邊緣數量變大，預設 Neptune 存取策略可能會變得效率低下。下列查詢可能會變得非常沒有效率：

  • 未提供邊緣標籤時，跨邊緣向後導覽的查詢。

  • 在內部使用此相同模式的子句，例如 .both() Gremlin，或捨棄任何語言節點的子句 （需要捨棄傳入邊緣而不了解標籤）。

  • 存取屬性值而不指定屬性標籤的查詢。這些查詢可能會變得非常沒有效率。如果這符合您的使用模式，請考慮啟用 OSGP 索引 （物件、主旨、圖形、述詞）。

使用慢查詢記錄來識別慢查詢。緩慢的查詢可能是由未最佳化的查詢計劃或不必要的大量索引查詢所造成，這可能會增加 I/O 成本。Gremlin、SPARQL 或 openCypher 的 Neptune 解釋和設定檔端點可協助您了解這些查詢緩慢的原因。原因可能包括下列項目：

  • 與圖形中的平均節點相比，邊緣數量異常高的節點 （例如，千個節點與數十個節點相比） 可能會增加運算複雜性，因此延遲更長，資源耗用量也更高。判斷這些節點是否已正確建模，或是否可以改善存取模式，以減少必須周遊的邊緣數量。

  • 未最佳化的查詢將包含未最佳化特定步驟的警告。重寫這些查詢以使用最佳化步驟可能會改善效能。

  • 備援篩選條件可能會導致不必要的索引查詢。同樣地，備援模式可能會導致重複的索引查詢，可透過改善查詢進行最佳化 （請參閱設定檔輸出Index Operations - Duplication ratio中的 )。

  • Gremlin 等某些語言沒有強式輸入的數值，而是改用類型提升。例如，如果值為 55，Neptune 會尋找整數、長數、浮點數和其他相當於 55 的數值類型。這會導致額外的操作。如果您事先知道您的類型相符，您可以使用查詢提示來避免這種情況。

  • 您的圖形模型可能會大幅影響效能。考慮使用更精細的標籤或將捷徑預先計算為多躍點線性路徑，以減少需要評估的物件數量。

如果僅查詢最佳化不允許您達到效能需求，請考慮搭配 Neptune 使用各種快取技術來達成這些需求。

Neptune 效能會隨著每個版本持續改善。檢閱版本備註，以查看每個版本改進的詳細資訊。請考慮規劃 Neptune 資料庫叢集的定期更新，以協助達到最佳效能。較新版本也支援較新的執行個體。請考慮升級至 1.4.5.0 或更新版本，以利用r8g執行個體。如需如何改善工作負載效能的詳細資訊，請參閱使用 Amazon Neptune 1.4.5 版搭配 AWS Graviton4 R8g 執行個體的 4.7 倍更好的寫入查詢價格效能。

適當大小的叢集

根據您的並行和輸送量需求調整叢集的大小。叢集中每個執行個體可處理的並行查詢數量等於該執行個體上虛擬 CPUs(vCPUs) 數量的兩倍。在佔用所有工作者執行緒時抵達的其他查詢會放入伺服器端佇列。當工作者執行緒可用時，這些查詢會以first-in-first-out(FIFO) 為基礎來處理。MainRequestQueuePendingRequests Amazon CloudWatch 指標會顯示每個執行個體目前的佇列深度。如果此值經常高於零，請考慮選擇具有更多 vCPU 的執行個體。 vCPUs 如果佇列深度超過 8，192，Neptune 將傳回ThrottlingException錯誤。

每個執行個體大約有 65% 的 RAM 保留給緩衝區快取。緩衝區快取會保留有效的資料集 （而非整個圖形；僅是查詢的資料）。若要判斷從緩衝區快取而非儲存體擷取的資料百分比，請監控 CloudWatch 指標 BufferCacheHitRatio。如果此指標通常低於 99.9%，請考慮嘗試具有更多記憶體的執行個體，以判斷其是否降低您的延遲和 I/O 成本。

僅供讀取複本的大小不必與寫入器執行個體相同。不過，繁重的寫入工作負載可能會導致較小的複本落後並重新啟動，因為它們無法跟上複寫的進度。因此，我們建議讓複本等於或大於寫入器執行個體。

為僅供讀取複本使用自動擴展時，請記住，最多可能需要 15 分鐘才能上線新的僅供讀取複本。當用戶端流量快速增加但可預測時，請考慮使用排程擴展來設定較高的僅供讀取複本數目下限，以考慮該初始化時間。

無伺服器執行個體支援數個不同的使用案例和工作負載。針對下列案例，請考慮在佈建執行個體上無伺服器：

  • 您的工作負載經常在一天中波動。

  • 您已建立新的應用程式，且不確定工作負載大小為何。

  • 您正在執行開發和測試。

請務必注意，無伺服器執行個體的成本高於每 GB RAM 的同等佈建執行個體。每個無伺服器執行個體都包含 2 GB 的 RAM，以及相關聯的 vCPU 和聯網。在您的選項之間執行成本分析，以避免意外帳單。一般而言，只有當您的工作負載每天只有幾個小時非常繁重，且一天的其餘時間幾乎為零，或您的工作負載在一天中大幅波動時，您才能透過無伺服器節省成本。

利用 Amazon Neptune 定價計算器，根據queries-per-second(QPS) 需求等因素，協助評估叢集的正確組態。

最佳化寫入

若要最佳化寫入，請考慮下列事項：

  • Neptune 大量載入器是最初載入資料庫或附加至現有資料的最佳方式。Neptune 載入器不是交易式且無法刪除資料，因此如果這些是您的需求，請勿使用它。

  • 您可以使用支援的查詢語言進行交易更新。若要最佳化寫入 I/O 操作，請批次寫入每個遞交 50-100 個物件的資料。物件是 LPG 中節點或邊緣上的節點、邊緣或屬性，或 RDF 中的三重存放區或四元組。

  • 所有交易 Neptune 寫入操作都是每個連線的單一執行緒。傳送大量資料至 Neptune 時，請考慮具有多個平行連線，每個連線都會寫入資料。當您選擇 Neptune 佈建執行個體時，執行個體大小會與多個 vCPUs相關聯。Neptune 會為執行個體上的每個 vCPU 建立兩個資料庫執行緒，因此在測試最佳平行處理時，從 vCPUs 數目的兩倍開始。  無伺服器執行個體會以大約每 4 個 NCUs 一個的速率擴展 vCPUs 數量。

    注意

    這不適用於大量載入 API，僅適用於直接連線。

  • 在所有寫入程序期間規劃並有效率地處理 ConcurrentModificationExceptions，即使一次只有單一連線正在寫入資料。在ConcurrentModificationExceptions發生時為用戶端設計可靠性。

  • 如果您想要刪除所有資料，請考慮使用快速重設 API，而不是發出並行刪除查詢。與前者相比，後者需要更長的時間並產生大量的 I/O 成本。

  • 如果您想要刪除大部分的資料，請考慮使用 neptune-export 將您要保留的資料匯出，以將資料載入新的叢集。然後刪除原始叢集。