本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 成本最佳化支柱
AWS Well-Architected Framework [的成本最佳化支柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html)著重於避免不必要的成本。下列建議可協助您符合 Amazon Neptune 的成本最佳化設計原則和架構最佳實務。
成本最佳化支柱著重於下列關鍵領域：
+ 了解一段時間內的支出並控制資金分配
+ 選取正確類型和數量的資源
+ 擴展以滿足業務需求，而不會過度花費
## 了解所需的用量模式和服務
如果您的資料模型具有可識別的圖形結構，且您的查詢需要探索關係並周遊多個躍點，Neptune 非常適合您的工作負載。圖形資料庫不適合下列模式：
+ 主要是單躍查詢 （考慮您的資料是否可更好地表示為物件的屬性）
+ 存放為屬性的 JSON 或 BLOB 資料
+ 跨資料集彙總的查詢，例如計算大量節點的數值屬性總和
考慮將多個專用資料庫結合用於特定存取模式，是否可以滿足您的所有需求。例如：
+ 使用 Neptune、DynamoDB 或 Amazon DocumentDB 中的一或多個項目，最適合顯示需要較少複雜圖形導覽以及高度並行擷取單一節點屬性的 API。
+ 關聯式資料庫可以與 Neptune 共存，以維護現有的功能，但僅在關聯式資料庫中執行和擴展不良的多躍點周遊使用 Neptune。
了解與 Neptune 互動和補充的 服務相關的成本，包括下列項目：
+ 大量載入 Neptune 的資料檔案的 Amazon Simple Storage Service (Amazon S3) 儲存成本
+ 用於插入或 upsert 查詢、讀取查詢和 Neptune 串流處理的 Lambda 函數
+ 建置在 Neptune 上的 API 層，可與 Amazon API Gateway 中的用戶端應用程式 （而非直接連線至資料庫） 互動，或 AWS AppSync
+ AWS Glue 用來往返 Neptune 傳輸資料的 任務
+ Amazon Kinesis 或 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 執行個體接收串流資料，以近乎即時的方式擷取至 Neptune。
+ AWS Database Migration Service 用於將關聯式資料遷移至 Neptune
+ Jupyter 筆記本和深度圖形程式庫機器學習模型的 Amazon SageMaker 執行期成本
## 選取關注成本的資源
[Neptune 定價](https://aws.amazon.com/neptune/pricing/)是根據每小時執行個體成本 （或無伺服器使用的 Neptune 運算單位）、資料 I/O 和儲存體用量。執行個體平均佔整體成本的 85%，因此適當調整大小可能會對成本產生重大影響。適當大小執行個體的最佳方法是在各種執行個體上測試應用程式效能，並比較下列因素：
+ `MainRequestQueuePendingRequests` CloudWatch 指標是否保持在接近零的一致低數？
+ `BufferCacheHitRatio` CloudWatch 指標大部分時間是否保持在 99.9% 以上？
+ 執行個體成本和相關聯資料 I/O 成本的成本和效能曲線是多少？ 需要經常將緩衝區快取交換與儲存體的執行個體大小過小，可能會大幅增加資料讀取成本。在這些情況下， `BufferCacheHitRatio`會經常下降。
執行個體成本會隨著相同執行個體系列中的大小線性擴展。`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 倍 ](https://aws.amazon.com/blogs/database/4-7-times-better-write-query-price-performance-with-aws-graviton4-r8g-instances-using-amazon-neptune-v1-4-5/)(AWS 部落格文章）。
Neptune 叢集預設為使用[標準儲存](https://docs.aws.amazon.com/neptune/latest/userguide/storage-types.html)體建立 （如果您使用主控台建立 ，則預設為選取 I/O 最佳化儲存體）。使用 I/O 最佳化儲存體時，您需要為儲存體和執行個體支付稍高的成本，但沒有 I/O 成本。這會導致更可預測的經常性成本，但如果您的 I/O 用量通常很低，利用標準儲存可能更具成本效益。如果您想要最初載入大量資料，您可以選擇 I/O 最佳化儲存、執行初始資料載入，然後切換到標準儲存，以最佳化成本。儲存類型只會影響帳單模型，且在 Neptune 資料庫叢集或執行個體組態中沒有技術差異。您可以每 30 天變更一次儲存類型。30 天後，請檢查您的詳細 Neptune 成本，並使用 [Neptune 定價頁面](https://aws.amazon.com/neptune/pricing/)來計算使用 I/O 最佳化儲存的成本是否會更高。如果可以的話，請繼續使用標準儲存，否則請切換回 I/O 最佳化。
## 為您的工作負載選擇最佳的 Neptune 執行個體組態
如果您在 2025 年 7 月 15 AWS 帳戶 日之前建立 ，則可以使用 [AWS 免費方案](https://aws.amazon.com/free/legacy/)進行 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 引擎統計資料](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-dfe-statistics.html)。使用`T`系列執行個體時，效能描述檔可能會明顯不同，尤其是先前提到的工作負載。這些執行個體也可以增加查詢瀏覽圖形大部分`OutOfMemoryExceptions`時的發生次數。若要判斷後者條件是否可能受到影響，請檢查 `BufferCacheHitRatio` CloudWatch 指標。
我們強烈建議您不要對`T`系列執行個體進行任何效能或負載測試，因為您可能會遇到不一致的結果，這些結果並不表示生產環境。
當您的工作負載相當穩定且可預測時，佈建的執行個體可為您提供最佳的成本和效能組合。根據所需的請求並行和查詢複雜性，選擇執行個體大小。較高的並行需要更多 vCPUs。較高的查詢複雜性需要更多 RAM。使用 `MainRequestQueuePendingRequests` CloudWatch 指標來判斷前者的影響 （大於零表示的並行請求多於可處理的請求）。使用 `BufferCacheHitRatio` CloudWatch 指標來判斷後者的影響。經常低於 99.9% 的比率表示沒有足夠的 RAM 來包含正在評估的圖形工作部分，這會導致更頻繁的快取交換。如果 R 系列執行個體提供足夠的並行但沒有足夠的 RAM，請考慮嘗試`X`一系列執行個體。
[Neptune 文件](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-serverless.html#neptune-serverless-uses)說明無伺服器執行個體的理想使用案例。如果您不確定佈建或無伺服器是否最適合您，而成本是您的主要考量，請在無伺服器中測試工作負載，以判斷使用的 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 定價計算器](https://pricingcalc.neptunedemos.com/)也提供比較，協助您決定最佳成本組態。
將無伺服器用於主要和複本執行個體時，請記住，提升層 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 執行個體，除非您已測試確認它們對您的工作負載造成重大影響。兩者都專為極少發生的案例而設計，而且它們可能會以最少或無收益的方式增加您的成本。