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

ISVs的操作最佳實務

本節中的許多指導方針適用於所有客戶的最佳實務，但它們已為 ISVs增加重要性。

使用最新版本更新您的 Neptune 叢集

在 Amazon Neptune 版本備註中，您可以看到每個版本都具有許多錯誤修正、效能改善和新功能。將 Neptune 叢集盡可能保持在最新版本上。

如果您在工作負載中發現先前未發現的錯誤，且叢集位於最新版本上，Neptune 工程師可以為您的叢集建立私有修補程式 （如果需要，且您想要）。修補程式可以橋接，直到該修正正式推出下一個版本為止。為了協助您將叢集更新至最新版本，請使用 Neptune 藍/綠解決方案。

使用差異而非刪除和取代資料擷取

您可以使用數種技術，將資料擷取或寫入 Neptune。許多客戶嘗試在每次收到變更時刪除並重新插入圖形，以簡化其資料擷取。它們可能會將last-modified屬性新增至每個節點，並定期掃描自某些指定日期以來尚未修改的節點，然後刪除它們。雖然這些技術簡化了資料擷取程序，但它們對您的 Neptune 叢集具有長期運作狀態和可擴展性影響。

首先，Neptune 使用字串的字典編碼。除非您明確指定節點和邊緣IDs，否則 Neptune 會產生以 ID 字串表示的 GUID，並將該字串存放在字典中。如果您持續刪除和新增物件，自動產生的 IDs 會在字典中造成膨脹。

其次，Neptune 可擴展至每秒最大擷取約 120 K 個物件。如果您持續刪除並新增物件，則會在實質上不會變更的物件上消耗大量頻寬。這會限制您可以在叢集上託管的租用戶數量、需要叢集中較大的寫入器執行個體，以及需要更多 I/O 操作。所有這些因素都會增加您的成本。

強烈建議您開發一種方法來計算已變更的真實差異，而不是使用刪除和新增方法。不過，某些資料來源不利於此 （例如，傳回目前狀態的 API 呼叫，或是未確切追蹤變更的事件）。如果您的原始資料來源不有利於識別變更，請使用擷取、轉換和載入 (ETL) 程序來計算差異。例如，您可以維持 Parquet 格式每個先前資料擷取的快照，使用 AWS Glue 計算這些快照之間的差異，並僅將差異推送至 Neptune。

模擬 Neptune 成本如何隨著租戶而演進

無論您使用孤立、集區或混合模型，雲端成本都會隨著租戶的大小而擴展。需要更多並行連線的租用戶需要比較少並行連線的執行個體或多個僅供讀取複本。這同樣適用於需要更快速資料擷取的租戶。

Neptune 叢集成本的三個元件包括執行個體大小 （和數量）、資料大小 (GB 月） 和 I/O 操作 （每百萬）。雖然這些成本通常是工作負載特定的，但它們會隨著大小和資料量而擴展，但可以使用 AWS 工具來測量。根據租戶大小的關鍵指標來追蹤和了解規模經濟，包括其大小隨著時間的變化。如果 I/O 費用的不可預測性影響您的利潤，請考慮選擇 Neptune I/O 最佳化儲存，以獲得更可預測的成本。

擴展叢集以滿足客戶需求

正確調整 Neptune 執行個體大小沒有嘗試過或真正的公式。Neptune 文件提供指引，但有太多變數可以建議直接映射。這些變數包括但不限於下列項目：

規劃測試，以判斷工作負載和租戶設定檔的最佳大小。一般而言，我們建議使用佈建的執行個體，以實現成本效益和可預測性。如果您的客戶體驗目標優先於成本的最佳擴展，請考慮使用 Neptune Serverless 執行個體，以確保無論工作負載波動如何，都能獲得更一致的體驗。

如果您的租戶讀取工作負載的尖峰和低谷有顯著差異，請將 Neptune Serverless 執行個體與 Neptune 自動調整規模結合。  新的僅供讀取複本初始化後，通常需要 10-15 分鐘才能上線。這表示僅自動擴展可以處理流量長時間變更，但不足以快速變更活動的峰值。透過結合 Neptune Serverless 和 Neptune 自動擴展，您可以向上或向下擴展執行個體，並向外擴展僅供讀取複本的數量。

如果您的租戶有顯著不同的工作負載描述檔或服務水準協議 (SLAs)，請考慮使用自訂端點和專用僅供讀取複本，將流量導向至該流量最佳化的執行個體。最佳化可包含不同大小的執行個體、特定查詢模式，或預暖緩衝快取。