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

成本最佳化支柱

AWS Well-Architected Framework 的成本最佳化支柱著重於避免不必要的成本。下列建議可協助您符合 Amazon Neptune 的成本最佳化設計原則和架構最佳實務。

成本最佳化支柱著重於下列關鍵領域：

了解所需的用量模式和服務

如果您的資料模型具有可識別的圖形結構，且您的查詢需要探索關係並周遊多個躍點，Neptune 非常適合您的工作負載。圖形資料庫不適合下列模式：

考慮將多個專用資料庫結合用於特定存取模式，是否可以滿足您的所有需求。例如：

了解與 Neptune 互動和補充的 服務相關的成本，包括下列項目：

選取關注成本的資源

Neptune 定價是根據每小時執行個體成本 （或無伺服器使用的 Neptune 運算單位）、資料 I/O 和儲存體用量。執行個體平均佔整體成本的 85%，因此適當調整大小可能會對成本產生重大影響。適當大小執行個體的最佳方法是在各種執行個體上測試應用程式效能，並比較下列因素：

執行個體成本會隨著相同執行個體系列中的大小線性擴展。db.r6i.2xlarge 執行個體的每小時成本是db.r6i.xlarge執行個體的兩倍，也是資源配置的兩倍。db.r6i.24xlarge 執行個體是db.r6i.xlarge執行個體每小時成本的 24 倍。

估計您必須支援的並行查詢數量。您可以有 0 到 15 個僅供讀取複本來處理唯讀查詢。如果您的需求因一天、一週或一個月的時間而有所不同，您可以使用多個較小的執行個體來根據排程進行擴展。執行個體上的每個 vCPU 提供兩個執行緒來處理並行查詢。三個僅供db.r6i.xlarge讀取複本各有 4 個 vCPU，可以處理 24 個並行查詢。

如果您的流量改為以每秒查詢數 (QPS) 來測量，您必須實驗以確定查詢的平均延遲。Neptune 叢集可支援的每秒查詢數等於 vCPU × 2 × (1 second/average query latency)。例如，如果您有 4 個 vCPU 且查詢延遲為 100 毫秒 (0.1 秒），則 QPS = 4 × 2 × (1s/0.1s) = 80 queries per second。

對於連續、穩定且可預測的工作負載，佈建的執行個體比無伺服器便宜。當您的工作負載每天只需要數小時 （例如 db.r6i.4xlarge) 使用量非常高，然後當天剩餘時間幾乎沒有流量 （例如 1 個 Neptune 運算單位），則無伺服器提供最佳化成本的機會。無伺服器執行個體會擴展數小時，然後再縮減，比起整天使用佈建的db.r6i.4xlarge執行個體來得便宜。

考慮升級至 Neptune 1.4.5.0 或更新版本，並利用r8g執行個體以低於 r7g或 等較舊世代執行個體的成本實現更佳的讀取和寫入輸送量r6g。如需詳細資訊，請參閱使用 Amazon Neptune v1.4.5 的 AWS Graviton4 R8g 執行個體寫入查詢價格效能提升 4.7 倍 (AWS 部落格文章）。

Neptune 叢集預設為使用標準儲存體建立 （如果您使用主控台建立 ，則預設為選取 I/O 最佳化儲存體）。使用 I/O 最佳化儲存體時，您需要為儲存體和執行個體支付稍高的成本，但沒有 I/O 成本。這會導致更可預測的經常性成本，但如果您的 I/O 用量通常很低，利用標準儲存可能更具成本效益。如果您想要最初載入大量資料，您可以選擇 I/O 最佳化儲存、執行初始資料載入，然後切換到標準儲存，以最佳化成本。儲存類型只會影響帳單模型，且在 Neptune 資料庫叢集或執行個體組態中沒有技術差異。您可以每 30 天變更一次儲存類型。30 天後，請檢查您的詳細 Neptune 成本，並使用 Neptune 定價頁面來計算使用 I/O 最佳化儲存的成本是否會更高。如果可以的話，請繼續使用標準儲存，否則請切換回 I/O 最佳化。

為您的工作負載選擇最佳的 Neptune 執行個體組態

如果您在 2025 年 7 月 15 AWS 帳戶 日之前建立 ，則可以使用 AWS 免費方案進行 Neptune 的入門級實驗。750 小時的免費 db.t3.medium和 db.t4g.medium執行個體用量足以讓您以低規模充分了解 Neptune。您的叢集將在免費試用期結束後保留，但從該時間點開始，您將需要支付使用費。

db.t3.medium 和 db.t4g.medium執行個體適用於您未使用 openCypher、Graph Explorer 或各種生成式 AI 整合的低成本開發環境。這些執行個體的 RAM-to-vCPU比率 (2：1) 小於R系列執行個體 (8：1) 或X系列執行個體 (16：1)。這可降低比率，防止使用啟用 openCypher 效能、GenAI 整合 （通知 LLM 圖形結構描述） 和 Graph Explorer 的 DFE 引擎統計資料。使用T系列執行個體時，效能描述檔可能會明顯不同，尤其是先前提到的工作負載。這些執行個體也可以增加查詢瀏覽圖形大部分OutOfMemoryExceptions時的發生次數。若要判斷後者條件是否可能受到影響，請檢查 BufferCacheHitRatio CloudWatch 指標。

我們強烈建議您不要對T系列執行個體進行任何效能或負載測試，因為您可能會遇到不一致的結果，這些結果並不表示生產環境。

當您的工作負載相當穩定且可預測時，佈建的執行個體可為您提供最佳的成本和效能組合。根據所需的請求並行和查詢複雜性，選擇執行個體大小。較高的並行需要更多 vCPUs。較高的查詢複雜性需要更多 RAM。使用 MainRequestQueuePendingRequests CloudWatch 指標來判斷前者的影響 （大於零表示的並行請求多於可處理的請求）。使用 BufferCacheHitRatio CloudWatch 指標來判斷後者的影響。經常低於 99.9% 的比率表示沒有足夠的 RAM 來包含正在評估的圖形工作部分，這會導致更頻繁的快取交換。如果 R 系列執行個體提供足夠的並行但沒有足夠的 RAM，請考慮嘗試X一系列執行個體。

Neptune 文件說明無伺服器執行個體的理想使用案例。如果您不確定佈建或無伺服器是否最適合您，而成本是您的主要考量，請在無伺服器中測試工作負載，以判斷使用的 NCUs 數量，並將佈建 (N hours × hourly provisioned cost) 的成本與無伺服器 () 進行比較sum of NCUs × hourly cost per NCU。如果您不確定同等大小的佈建執行個體，一個 NCU 相當於大約 2 GB 的 RAM 和相關聯的 vCPU 和聯網。如果您的佈建執行個體來自 r6i 系列，則比率為每 8 GB RAM 1 個 vCPU，或 4 NCUs，以及相關聯的聯網。Amazon Neptune 定價計算器也提供比較，協助您決定最佳成本組態。

將無伺服器用於主要和複本執行個體時，請記住，提升層 0 和 1 中的僅供讀取複本會根據寫入器執行個體擴展其 NCUs，以便在容錯移轉事件發生時適當擴展。根據寫入器或讀取器接收最多流量的執行個體，設定這些執行個體的 NCU 限制。

在每週 7 天、每天 24 小時不需要叢集的環境中，請考慮撰寫指令碼，以在不使用時關閉 Neptune 執行個體，並在使用前再次啟動它們。Neptune 執行個體會每 7 天自動重新啟動一次，以確保套用必要的維護更新。如果您想要讓執行個體長時間關閉，請使用每週指令碼再次將其關閉。

適當大小的資料儲存和傳輸

更有效率的查詢 （例如，需要接觸圖形中較少節點、邊緣和屬性的查詢） 需要較少的 I/O 傳輸，而且可能會利用較小的執行個體，因為需要較少的緩衝區快取。使用設定檔或解釋查詢語言的端點來最佳化查詢，並考慮針對查詢效能最佳化您的圖形模型。

Neptune 在大型字串上使用字典編碼，該字典針對效能進行了最佳化，而非效率。如果您有大型 BLOBs、JSON 或經常變更屬性的字串，請考慮將它們存放在 Amazon S3、Amazon DynamoDB 或 Amazon DocumentDB 的 Neptune 外部，並在 Neptune 節點中僅存放參考。

在某些情況下，選擇較大的執行個體大小可能會比較便宜。如果您的 I/O 成本因為 較低而很高BufferCacheHitRatio，則較大的緩衝區快取可能會大幅降低該成本。這是因為所有資料都適合快取，而不是經常從儲存體交換並產生 I/O 傳輸速率。

Neptune 使用copy-on-write。複製將圖形分割成多個碎片時，最好不要刪除複製叢集上不需要的資料，因為這將涉及建立新資料頁面，進而增加儲存成本。在複製事件之前未變更的資料將存在於跨兩個叢集共用的單一資料頁面中，並且只會針對該單一複本收費。

請勿啟用 OSGP 索引或使用 R5d 執行個體，除非您已測試確認它們對您的工作負載造成重大影響。兩者都專為極少發生的案例而設計，而且它們可能會以最少或無收益的方式增加您的成本。