本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 为 Amazon Neptune 选择实例类型
Amazon Neptune 提供了许多不同的实例大小和系列，它们提供了适合不同图形工作负载的不同功能。本节旨在帮助您选择最适合您需求的实例类型。
有关这些系列中每种实例类型的定价，请参阅 [Neptune 定价页面](https://aws.amazon.com/neptune/pricing/)。
## 实例资源分配概述
Neptune 中使用的每种 Amazon EC2 实例类型和大小都提供一定数量的计算 (vCPUs) 和系统内存。Neptune 的主存储位于集群中数据库实例的外部，这使得计算和存储容量可以相互独立扩展。
本节重点介绍如何扩展计算资源，以及每种不同实例系列之间的差异。
在所有实例系列中，都将分配 vCPU 资源以便每个 vCPU 支持两 (2) 个查询执行线程。这种支持由实例大小决定。在确定给定 Neptune 数据库实例的适当大小时，您需要考虑应用程序可能的并发性以及查询的平均延迟。您可以按如下方式估算CPUs 所需的 v 数，其中延迟按平均查询延迟（以秒为单位）来衡量，并发度按每秒的目标查询数来衡量：
```
vCPUs = (latency x concurrency) / 2
```
**注意**
在某些情况下，使用 DFE 查询引擎的 SPARQL 查询、openCypher 查询和 Gremlin 读取查询可以为每个查询使用多个执行线程。在最初调整数据库集群大小时，首先假设每个查询每次执行将消耗单个执行线程，如果您观察到查询队列中有背压，则可以纵向扩展。这可以通过使用`/gremlin/status``/oc/status`、或来观察 `/sparql/status` APIs，也可以使用`MainRequestsPendingRequestsQueue` CloudWatch 指标进行观察。
每个实例上的系统内存分为两个主要分配：缓冲池缓存和查询执行线程内存。
实例中大约有三分之二的可用内存分配给缓冲池缓存。缓冲池缓存用于缓存图形中最近使用的组件，以便更快地访问重复访问这些组件的查询。系统内存量较大的实例具有较大的缓冲池缓存，可以在本地存储更多的图形。用户可以通过监控中可用的缓冲区缓存命中和未命中指标来调整缓冲池缓存的适当量。 CloudWatch
如果缓存命中率持续降至 99.9% 以下，则可能需要增加实例的大小。这表明缓冲池不够大，引擎不得不更高效、更频繁地从底层存储卷提取数据。
其余三分之一的系统内存在各个查询执行线程之间均匀分布，一些内存留给操作系统，还有一个小型动态池供线程根据需要使用。每个线程的可用内存从一个实例大小略微增加到下一个实例大小，直至 `8xl` 实例类型，达到该大小后，每个线程分配的内存达到最大值。
当您遇到 `OutOfMemoryException` (OOM) 时，则是时候添加更多线程内存了。当一个线程需要的内存超过分配给它的最大内存时，就会出现 OOM 异常（这与整个实例耗尽内存不同）。
## `t3` 和 `t4g` 实例类型
`t3` 和 `t4g` 实例系列为开始使用图形数据库以及初始开发和测试提供了一种低成本的选项。这些实例有资格享受 Neptune [免费套餐优惠](https://aws.amazon.com/neptune/free-trial/)，该优惠允许新客户在独立 AWS 账户中使用的前 750 个实例小时内免费使用 Neptune，或者累积到具有整合账单的 AWS 组织（付款人账户）下。
`t3` 和 `t4g` 实例仅在中型配置（`t3.medium` 和 `t4g.medium`）中提供。
它们不适用于生产环境。
由于这些实例的资源非常有限，因此不建议将其用于测试查询执行时间或数据库整体性能。要评测查询性能，请升级到其它实例系列之一。
## `r4` 实例类型系列
*已弃用* – `r4` 系列是在 2018 年 Neptune 推出时提供的，但现在更新的实例类型提供了高得多的性价比。从引擎版本 [1.1.0.0](engine-releases-1.1.0.0.md) 开始，Neptune 不再支持 `r4` 实例类型。
## `r5` 实例类型系列
`r5` 系列包含内存优化型实例类型，适用于大多数图形用例。`r5` 系列包含的实例类型从 `r5.large` 直至 `r5.24xlarge`。随着大小增加，它们的计算性能会线性扩展。例如，一个`r5.xlarge`（4 v CPUs 和 32GiB 的内存）的 v 和内存是 a 的两倍`r5.large`（2 v CPUs CPUs 和 16GiB 的内存），而`r5.2xlarge`（8 v 和 64GiB 的内存）的 v CPUs 和内存是 a 的两倍。CPUs `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 索引存储中获取数据时，属性值和 RDF 字面值会缓存在此卷中。 NVMe
如果您不需要查找缓存特征，请使用标准 `r5` 实例类型而不是 `r5d`，以避免更高的 `r5d` 成本。
`r5d` 系列的实例类型与 `r5` 系列的大小相同（从 `r5d.large` 到 `r5d.24xlarge`）。
## `r6g` 实例类型系列
AWS 已经开发了自己的基于ARM的处理器，名为 [Graviton](https://aws.amazon.com/ec2/graviton/)，其性能优 price/performance 于英特尔和AMD的同类处理器。`r6g` 系列使用 Graviton2 处理器。在我们的测试中，Graviton2 处理器在 OLTP 风格（受限）图形查询方面的性能提高了 10-20%。但是，由于内存分页性能略低，使用 Graviton2 处理器时更大的 OLAP 类查询的性能可能略低于 Intel 处理器。
还需要注意的是，`r6g` 系列采用单插槽架构，这意味着随着计算容量从 `r6g.large` 到 `r6g.16xlarge`（该系列中的最大类型），性能将线性扩展。
## `r6i` 实例类型系列
[Amazon R6i 实例](https://aws.amazon.com/ec2/instance-types/r6i/)由第三代 Intel Xeon 可扩展处理器（代号为 Ice Lake）提供支持，非常适合内存密集型工作负载。一般来说，与同类的 R5 实例类型相比，它们的计算性价比高出多达 15%，每个 vCPU 的内存带宽高出多达 20%。
## `x2g` 实例类型系列
当实例的缓冲池缓存较大时，某些图形用例的性能会更好。推出 `x2g` 系列是为了更好地支持这些用例。该`x2g`家庭的 memory-to-vCPU比例大于`r5`或`r6g`家族。`x2g` 实例还使用 Graviton2 处理器，具有许多与 `r6g` 实例类型相同的性能特征，而且缓冲池缓存更大。
如果您使用的是 CPU 利用率低且缓冲池缓存未命中率高的 `r5` 或 `r6g` 实例类型，请尝试改用 `x2g` 系列。这样，您就可以获得所需的额外内存，而无需为更多 CPU 容量付费。
## `x2iezn` 实例类型系列
该`x2iezn`系列提供内存优化型实例，这些实例由英特尔至强可扩展处理器提供支持，具有高频性能。这些实例提供高 memory-to-vCPU比率（每个 vCPU 32 GiB），因此非常适合受益于高单线程性能的内存密集型图形工作负载。
主要功能包括高达 4.5 的 GHz 全核 turbo 频率，以及从 2xlarge 到 12xlarge 的尺寸可供选择。
## `x2iedn` 实例类型系列
该`x2iedn`系列为内存优化型实例提供本地 NVMe SSD 存储。这些实例将高内存容量（每个 vCPU 32 GiB）与快速本地存储相结合，非常适合同时受益于大型内存缓存和高性能本地磁盘缓存的图形工作负载。
这些实例由第三代英特尔至强可扩展处理器提供支持，大小从 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 风格的分析工作负载的出色 price/performance 比率
+ 改进的内存管理功能，有利于复杂的图形遍历
`r8g` 系列非常适合需要高内存容量和稳定性能的生产工作负载。它们对于查询并发度要求高的应用程序特别有效。
## `r7g` 实例类型系列
该`r7g`系列使用 AWS Graviton3处理器，其性能 price/performance 比以前基于Graviton2的实例要好。在测试中，与 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 实例相比，有了显著改进。 price/performance 与同类的 r6i 实例类型相比，这些实例的计算能力提高了大约 15%，每个 vCPU 的内存带宽最多可提高 20%。
与 `r5` 系列一样，`r7i` 实例系列采用双插槽 Intel CPU 架构。`r7i.12xlarge` 和更小的类型使用单插槽和该单插槽处理器拥有的系统内存。`r7i.16xlarge` 和 `r7i.24xlarge` 类型使用这两个插槽和可用内存。由于在双插槽架构中，两个物理处理器之间需要一些内存管理开销，因此从 `r7i.12xlarge` 扩展到 `r7i.16xlarge` 或 `r7i.24xlarge` 实例类型的性能增益并不像在较小大小上纵向扩展时那样线性。
`r7i` 系列的主要功能包括：
+ 由第四代 Intel Xeon 可扩展处理器提供支持
+ 随着计算容量增至 r7i.12xlarge，性能线性扩展
+ 采用双插槽架构，增强了物理处理器之间的内存管理
+ 内存密集型图形操作的性能有所提高
对于所有这些实例系列，您可以使用前面提到的相同公式来估算CPUs 所需的 v 数：
```
vCPUs = (latency x concurrency) / 2
```
其中延迟按平均查询延迟（以秒为单位）来衡量，并发度按每秒的目标查询数来衡量。
## `serverless` 实例类型
[Neptune 无服务器](neptune-serverless.md)特征可以根据工作负载的资源需求动态扩展实例大小。Neptune Serverless 允许您为数据库集群中的实例[设置计算容量的下限和上限（以 Neptune 容量](neptune-serverless-capacity-scaling.md)单位衡量），而不是计算应用程序需要多少 v CPUs 。使用无服务器实例而不是预调配实例可以对具有不同利用率的工作负载进行成本优化。
您可以在同一个数据库集群中同时设置预调配实例和无服务器实例，以实现最佳性价比配置。