本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 選擇 Amazon Neptune 的執行個體類型 Amazon Neptune 提供許多不同的執行個體大小和系列，提供適合於不同圖形工作負載的不同功能。本節旨在協助您選擇符合需求的最佳執行個體類型。 如需這些系列中每個執行個體類型的定價，請參閱 [Neptune 定價頁面](https://aws.amazon.com/neptune/pricing/)。 ## 執行個體資源配置的概觀 Neptune 中使用的每個 Amazon EC2 執行個體類型和大小都會提供定義的運算 (vCPU) 和系統記憶體數量。Neptune 的主要儲存體位於叢集中的資料庫執行個體外部，可讓運算和儲存容量彼此獨立擴展。 本節專注於運算資源的擴展方式，以及各種不同執行個體系列之間的差異。 在所有執行個體系列中，都會配置 vCPU 資源以支援每個 vCPU 兩 (2) 個查詢執行執行緒。此支援是由執行個體大小決定。確定給定 Neptune 資料庫執行個體的適當大小時，您需要考慮應用程式可能的並行性，以及查詢的平均延遲。您可以按照以下方式估計所需的 vCPU 數目，其中延遲是以平均查詢延遲來測量 (以秒為單位)，而並行性是以每秒的目標查詢數目來測量： ``` vCPUs = (latency x concurrency) / 2 ``` **注意** 使用 DFE 查詢引擎的 SPARQL 查詢、OpenCypher 查詢和 Gramlin 讀取查詢，可以在某些情況下每個查詢使用多個執行緒。在最初調整資料庫叢集的大小時，請先假設每個查詢每次執行都會取用單一執行緒，並且如果您觀察到有背壓進入查詢佇列，則會縱向擴展。這可以使用 `/gremlin/status`、`/oc/status` 或 `/sparql/status` API 觀察到此情況，也可以使用 `MainRequestsPendingRequestsQueue` CloudWatch 指標來觀察。 每個執行個體上的系統記憶體分為兩個主要配置：緩衝集區快取和查詢執行緒記憶體。 執行個體中約有三分之二的可用記憶體會配置給緩衝集區快取。緩衝集區快取用來快取圖形的最近使用元件，以便重複存取這些元件的查詢可以進行更快的存取。具有較大系統記憶體數量的執行個體擁有較大的緩衝集區快取，可在本機儲存更多圖形。使用者可以透過監控 CloudWatch 中可用的緩衝區快取命中和遺漏指標，來調校適當的緩衝集區快取數量。 如果快取命中率始終在一段時間內掉至 99.9% 以下，您可能會想要增加執行個體的大小。這表明緩衝集區不夠大，而且引擎必須頻繁地從基礎儲存磁碟區擷取資料。 剩餘的三分之一系統記憶體會平均分佈在查詢執行緒之間，還有一些記憶體留給作業系統和小型動態集區，供執行緒視需要使用。每個執行緒可用的記憶體會從一個執行個體大小略為增加到下一個執行個體大小，直到 `8xl` 執行個體類型，此大小會使每個執行緒配置的記憶體達到上限。 新增更多執行緒記憶體的時機，就是您遇到 `OutOfMemoryException` (OOM)。當一個執行緒需要超過配置給它的記憶體上限時，就會發生 OOM 例外狀況 (這與整個執行個體耗盡記憶體不同)。 ## `t3` 和 `t4g` 執行個體類型 執行個體的 `t3` 和 `t4g` 系列提供低成本選項，用於開始使用圖形資料庫，也可用於初始開發和測試。這些執行個體符合 Neptune [免費方案優惠](https://aws.amazon.com/neptune/free-trial/)的資格，可讓新客戶在獨立 AWS 帳戶中使用的前 750 個執行個體小時內免費使用 Neptune，或在 Organization AWS with Consolidated Billing （付款人帳戶） 下彙總。 `t3` 和 `t4g` 執行個體僅以中型組態 ( `t3.medium` 和 `t4g.medium`) 提供。 它們不適用於生產環境。 因為這些執行個體具有的資源非常有限，所以不建議用於測試查詢執行時間或整體資料庫效能。若要評估查詢效能，請升級至其他執行個體系列之一。 ## 執行個體類型的 `r4` 系列 *已棄用* – `r4` 系列是在 Neptune 於 2018 年推出時提供的，但現在有較新的執行個體類型可提供更好的價格/效能。從引擎 [1.1.0.0](engine-releases-1.1.0.0.md) 版開始，Neptune 不再支援 `r4` 執行個體類型。 ## 執行個體類型的 `r5` 系列 `r5` 系列包含記憶體優化執行個體類型，適用於大多數圖形使用案例。`r5` 系列包含從 `r5.large` 最高可至 `r5.24xlarge` 的執行個體。隨著大小的增加，它們會以線性方式擴展運算效能。例如，`r5.xlarge` (4 個 vCPU 和 32GiB 記憶體) 具有的 vCPU 和記憶體是 `r5.large` (2 個 vCPU 和 16GiB 記憶體) 的兩倍，而 `r5.2xlarge` (8 個 vCPU 和 64GiB 記憶體) 具有的 vCPU 和記憶體是 `r5.xlarge` 的兩倍 您可以預期查詢效能會隨著運算容量直接最高擴展至 `r5.12xlarge` 執行個體類型。 `r5` 執行個體系列具有雙插槽 Intel CPU 架構。`r5.12xlarge` 和較小的類型會使用單插槽和該單插槽處理器所擁有的系統記憶體。`r5.16xlarge` 和 `r5.24xlarge` 類型會使用這兩個插槽和可用記憶體。因為雙插槽架構中的兩個實體處理器之間需要一些記憶體管理負荷，所以從 `r5.12xlarge` 擴展到 `r5.16xlarge` 或 `r5.24xlarge` 執行個體類型的效能提升並不像您以較小的大小縱向擴展那樣呈線性提升。 ## 執行個體類型的 `r5d` 系列 Neptune 具有[查詢快取功能](feature-overview-lookup-cache.md)，可以用來改善需要擷取和傳回大量屬性值和常值之查詢的效能。此功能主要是由需要使用查詢傳回許多屬性的客戶使用。查詢快取會本機擷取這些屬性值，而不是在 Neptune 索引儲存區中反覆查詢每個屬性值，藉此提升這些查詢的效能。 查詢快取是使用 `r5d` 執行個體類型上 NVMe 連接的 EBS 磁碟區來實作。它是使用叢集的參數群組來啟用。從 Neptune 索引儲存區擷取資料時，會在此 NVMe 磁碟區內快取屬性值和 RDF 常值。 如果您不需要查詢快取功能，請使用標準 `r5` 執行個體類型，而非 `r5d`，以避免更高成本的 `r5d`。 `r5d` 系列具有與 `r5` 系列大小相同的執行個體類型 (從 `r5d.large` 到 `r5d.24xlarge`)。 ## 執行個體類型的 `r6g` 系列 AWS 已開發自己的 ARM 型處理器，稱為 [Graviton](https://aws.amazon.com/ec2/graviton/)，可提供比 Intel 和 AMD 同等產品更好的價格/效能。`r6g` 系列使用 Graviton2 處理器。在我們的測試中，Graviton2 處理器可為 OLTP 樣式 (受限) 圖形查詢提供 10-20％ 的效能提升。不過，由於記憶體分頁效能的表現稍差，因此使用 Graviton2 處理器時，較大的 OLAP-ish 查詢效能可能會略低於 Intel 處理器的查詢效能。 另外務必要注意的是，`r6g` 系列具有單插槽架構，這意味著效能會隨著運算容量以線性方式從 `r6g.large` 擴展到 `r6g.16xlarge` (系列中最大的類型)。 ## 執行個體類型的 `r6i` 系列 [Amazon R6i 執行個體](https://aws.amazon.com/ec2/instance-types/r6i/)是由第三代 Intel Xeon 可擴展處理器 (名為 Ice Lake 的程式碼) 提供，非常適合於記憶體密集型工作負載。一般而言，與同類 R5 執行個體類型相比，每個 vCPU 可提升高達 15% 的運算價格效能，以及高達 20% 的記憶體頻寬。 ## 執行個體類型的 `x2g` 系列 當執行個體具有較大的緩衝集區快取時，某些圖形使用案例可以看到更好的效能。推出 `x2g` 系列是為了更好地支援這些使用案例。`x2g` 系列具有的記憶體與 vCPU 比率大於 `r5` 或 `r6g` 系列。`x2g` 執行個體也會使用 Graviton2 處理器，並具有許多與 `r6g` 執行個體類型相同的效能特性，以及較大的緩衝集區快取。 如果您使用的 `r5`或 `r6g`執行個體類型具有低 CPU 使用率和高緩衝集區快取遺漏率，請嘗試改用 `x2g` 系列。如此一來，您將取得所需的額外記憶體，而無需支付更多 CPU 容量。 ## 執行個體類型的 `x2iezn` 系列 `x2iezn` 系列提供採用 Intel Xeon 可擴充處理器且具有高頻率效能的記憶體最佳化執行個體。這些執行個體提供高memory-to-vCPU比率 （每個 vCPU 32 GiB)，非常適合記憶體密集型圖形工作負載，而這些工作負載受益於高單一執行緒效能。 主要功能包括高達 4.5 GHz 的全核心渦輪頻率，以及大小從 2xlarge 到 12xlarge 的可用性。 ## 執行個體類型的 `x2iedn` 系列 `x2iedn` 系列提供具有本機 NVMe SSD 儲存體的記憶體最佳化執行個體。這些執行個體結合了高記憶體容量 （每個 vCPU 32 GiB) 和快速本機儲存，因此非常適合受益於大型記憶體內快取和高效能本機磁碟快取的圖形工作負載。 這些執行個體採用第三代 Intel Xeon 可擴充處理器，提供 xlarge 到 32xlarge 的大小，並針對需要記憶體和儲存效能的大型圖形資料庫進行最佳化。 ## 執行個體類型的 `r8g` 系列 `r8g` 系列包含採用 AWS Graviton4 處理器的記憶體最佳化執行個體類型。相較於前幾代，這些執行個體提供了顯著的效能改善，使其非常適合記憶體密集型圖形工作負載。相較於 r7g 執行個體，r8g 執行個體可為圖形查詢提供大約 15-20% 更好的效能。 `r8g` 系列使用雙插槽平台。從 `r8g.large` 到 在單一通訊端`r8g.24xlarge`上執行的執行個體類型，這表示效能會隨著該範圍的運算容量線性擴展。`r8g.48xlarge` 使用兩個通訊端， 是系列中最大的執行個體類型；如同其他雙通訊端系列一樣，從 擴展`r8g.24xlarge`到 時，由於跨通訊端記憶體管理額外負荷，`r8g.48xlarge`效能可能不會完美線性。 `r8g` 系列的主要功能包括： + 採用 AWS Graviton4 ARM 型處理器 + 相較於前幾代，每個 vCPU 的記憶體頻寬更高 + OLTP 型 （受限） 圖形查詢和 OLAP 型分析工作負載的卓越價格/效能比率 + 改善記憶體管理功能，有利於複雜的圖形周遊 `r8g` 系列非常適合需要高記憶體容量和一致效能的生產工作負載。它們對於具有高查詢並行需求的應用程式特別有效。 ## 執行個體類型的 `r7g` 系列 `r7g` 系列使用 AWS Graviton3 處理器，可提供比先前Graviton2-based執行個體更好的價格/效能。在測試中，相較於 r6g 執行個體，Graviton3 處理器可為 OLTP 樣式的圖形查詢提供 25-30% 更好的效能。 與 `r6g` 系列相同， `r7g` 系列具有單一插槽架構，這表示效能會隨著運算容量從 線性擴展`r7g.large`至 `r7g.16xlarge`（系列中最大的類型）。 `r7g` 系列的主要功能包括： + 採用 AWS Graviton3 ARM 型處理器 + 相較於 r6g 改善記憶體分頁效能，同時受益於 OLTP 和 OLAP 工作負載 + 增強的緩衝集區快取效率 + 降低記憶體密集型操作的延遲 `r7g` 系列非常適合具有各種查詢模式的生產環境，對於受益於改善記憶體頻寬的工作負載特別有效。 ## 執行個體類型的 `r7i` 系列 `r7i` 系列採用第四代 Intel Xeon 可擴充處理器 （名為 Sapphire Rapids 的程式碼），可大幅改善 r6i 執行個體。相較於類似的 r6i 執行個體類型，這些執行個體可提供大約 15% 的運算價格/效能，以及每個 vCPU 高達 20% 的記憶體頻寬。 `r7i` 執行個體系列具有 2 個插槽的 Intel CPU 架構，類似於 `r5` 系列。`r7i.12xlarge` 和較小的類型會使用單插槽和該單插槽處理器所擁有的系統記憶體。`r7i.16xlarge` 和 `r7i.24xlarge` 類型會使用這兩個插槽和可用記憶體。因為雙插槽架構中的兩個實體處理器之間需要一些記憶體管理負荷，所以從 `r7i.12xlarge` 擴展到 `r7i.16xlarge` 或 `r7i.24xlarge` 執行個體類型的效能提升並不像您以較小的大小縱向擴展那樣呈線性提升。 `r7i` 系列的主要功能包括： + 採用第四代 Intel Xeon 可擴充處理器 + 效能會隨著運算容量線性擴展，最高可達 r7i.12xlarge + 2 插槽架構中實體處理器之間的增強記憶體管理 + 改善記憶體密集型圖形操作的效能 對於所有這些執行個體系列，您可以使用先前提到的相同公式來估計所需的 vCPUs 數量： ``` vCPUs = (latency x concurrency) / 2 ``` 其中延遲測量為平均查詢延遲，以秒為單位，並行測量為每秒的目標查詢數。 ## `serverless` 執行個體類型 [Neptune Serverless](neptune-serverless.md) 功能可以根據工作負載的資源需求動態擴展執行個體大小。Neptune Serverless 可讓您為資料庫叢集中的執行個體[設定運算容量的下限和上限](neptune-serverless-capacity-scaling.md) (以 Neptune 容量單位測量)，而不是計算您的應用程式需要多少 vCPU。具有不同使用率的工作負載可以使用無伺服器而不是佈建的執行個體進行成本最佳化 您可以在相同的資料庫叢集中同時設定佈建執行個體和無伺服器執行個體，以實現最佳的成本效能組態。