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

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

效能效率支柱

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

  • 確認業務需求

  • 測量工作負載效能

  • 識別效能不佳的元件

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

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

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

  • 圖形建模

  • 查詢最佳化

  • 叢集大小正確

  • 寫入最佳化

了解圖形建模

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

如果您要建置軟體即服務 (SaaS) 應用程式或需要多租用戶的應用程式，請考慮將租用戶的邏輯分離併入資料模型，而不是每個叢集有一個租用戶。若要實現該類型的設計，您可以使用名為 SPARQL 的圖形和標籤策略，例如將客戶識別符新增至標籤，或新增代表租用戶識別符的屬性鍵值對。確保您的用戶端層注入這些值，以保持該邏輯分隔。

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

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

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

最佳化查詢

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

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

Neptune 已針對從單一節點或一組節點開始的交易類型查詢進行最佳化，並從那裡散出，而不是評估整個圖形的分析查詢。對於分析查詢工作負載，請考慮使用適用於 Pandas 的 AWS 開發套件，或使用 neptune-export 結合 AWS Glue或 Amazon EMR。

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

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

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

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

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

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

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

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

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

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

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

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

正確大小的叢集

根據您的並行和輸送量需求調整叢集的大小。叢集中每個執行個體可處理的並行查詢數量等於該執行個體上虛擬 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 和聯網。在您的選項之間執行成本分析，以避免意外帳單。一般而言，只有當工作負載每天只有數小時非常繁重，且一天的其餘時間幾乎為零，或工作負載在一天中大幅波動時，您才能透過無伺服器節省成本。

最佳化寫入

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

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

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

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

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

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

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