本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Amazon Neptune 基本操作指导
以下是使用 Neptune 时您应遵循的基本操作指导。
了解 Neptune 数据库实例，以便您可以根据自己的性能和用例要求适当调整其大小。请参阅Amazon Neptune 数据库集群和实例。
-
监控您的 CPU 和内存使用情况。这有助于您了解何时迁移到具有更大 CPU 或内存容量的数据库实例类，以实现您所需的查询性能。可将 Amazon CloudWatch 设置为在使用模式发生更改或接近部署容量时向您发送通知。这样做可以帮助您维护系统性能和可用性。有关详细信息，请参阅 监控实例 和 监控 Neptune。
由于 Neptune 具有自己的内存管理器，即使 CPU 使用率较高，相对较低的内存使用率也是正常的。执行查询时遇到内存不足异常的情况表明您最好增加可用内存。
启用自动备份并设置备份时段，使备份在便利的时段进行。
-
测试您的数据库实例的故障转移，以了解对于您的使用案例而言，该过程需要多长时间。它还有助于确保访问您数据库实例的应用程序在故障转移之后可以自动连接到新数据库实例。
-
如果可能，请在同一区域和 VPC 中运行您的客户端和 Neptune 集群，因为使用 VPC 对等连接的跨区域连接可能会导致查询响应时间的延迟。对于几个毫秒的查询响应，需要将客户端和 Neptune 集群保留在同一个区域和 VPC 中。
-
在创建只读副本实例时，该实例至少应与主写入器实例一样大。这有助于阻止复制滞后，并避免副本重新启动。请参阅避免在集群中使用不同的实例类。
-
在升级到新的主要引擎版本之前，请务必在升级之前在其上测试您的应用程序。为此，您可以克隆数据库集群，使克隆集群运行新的引擎版本，然后在克隆上测试您的应用程序。
-
为了便于进行故障转移，理想情况下，所有实例的大小应相同。
主题
Amazon Neptune 安全最佳实践
使用 Amazon Identity and Access Management (IAM) 账户控制对 Neptune API 操作的访问权限。控制创建、修改或删除 Neptune 资源（如数据库实例、安全组、选项组或参数组）的操作，以及执行常见管理操作（如备份和还原数据库实例）的操作。
尽可能使用临时凭证而不是永久凭证。
为每个管理 Amazon Relational Database Service (Amazon RDS) 资源的用户分配一个 IAM 账户。切勿使用 Amazon 账户根用户来管理 Neptune 资源。为每个人（包括您自己）创建一个 IAM 用户。
授予每位用户执行其职责所需的最小权限集。
使用 IAM 组有效地管理适用于多个用户的权限。
定期交替 IAM 凭证。
有关使用 IAM 访问 Neptune 资源的更多信息，请参阅Amazon Neptune 中的安全性。有关使用 IAM 的一般信息，请参阅《IAM 用户指南》中的 Amazon Identity and Access Management 和 IAM 最佳实践。
避免在集群中使用不同的实例类
当您的数据库集群包含不同类的实例时，可能会随着时间推移而出现问题。最常见的问题是，由于复制滞后，小的读取器实例可能会进入重复重启循环。如果读取器节点的数据库实例类配置比写入器数据库实例的配置弱，则更改量可能太大，读取器无法跟上。
重要
为避免复制滞后导致重复重启，请配置您的数据库集群，使所有实例具有相同的实例类（大小）。
您可以使用 Amazon CloudWatch 中的 ClusterReplicaLag 指标，查看数据库集群中的写入器实例（主实例）和读取器之间的滞后。VolumeWriteIOPs 指标还允许您检测集群中可能造成复制滞后的写入活动突发情况。
避免在批量加载期间重复重启
如果您在批量加载期间由于复制滞后而经历了重复重启只读副本的循环，则您的副本可能无法跟上数据库集群中写入器的速度。
要么将读取器扩展到比写入器大，要么在批量加载期间暂时将它们移除，然后在完成后重新创建。
如果您的谓词数量很多，则启用 OSGP 索引
如果您的数据模型包含大量不同的谓词（大多数情况下超过 1000），则可能会面临性能降低和更高的运营成本。
在这种情况下，您可以通过启用 OSGP 索引来提高性能。请参阅OSGP 索引。
尽可能避免长时间运行的事务
长时间运行的事务（无论是只读事务还是读写事务）可能导致以下类型的意外问题：
读取器实例或具有并发写入的写入器实例上长时间运行的事务可能会导致大量累积不同版本的数据。这可能会给筛选掉大部分结果的读取查询带来更高的延迟。
在某些情况下，数小时内累积的版本可能会导致新的写入受到节流。
如果实例重启，长时间运行且写入次数较多的读写事务也可能导致问题。如果实例因维护事件或崩溃而重启，则将回滚所有未提交的写入操作。此类撤消操作通常在后台运行，不会阻止实例恢复正常，但是任何与正在回滚的操作冲突的新写入操作都会失败。
例如，如果在上一次运行中断开连接后重试同一查询，则实例重启时查询可能会失败。
撤消操作所需的时间与所涉及更改的大小成正比。
使用 Neptune 指标的最佳实践
要确定因资源不足和其它常见瓶颈导致的性能问题，您可以监控可用于 Neptune 数据库集群的指标。
定期监控性能指标以收集有关各种时间范围内的平均值、最大值和最小值数据。这可帮助确定性能下降的时间。使用此数据，您可以针对特定指标阈值设置 Amazon CloudWatch 警报，以便在达到这些阈值时向您发出警报。
设置新的数据库集群并让它在典型工作负载下运行时，尝试按一些不同的间隔（例如，一小时、二十四小时、一周、两周）来捕获所有性能指标的平均值、最大值和最小值。这将使您能够了解运行状况。这有助于将操作的峰值时间与非峰值时间进行比较。您随后可以利用这些信息确定性能何时降到标准水平以下，然后相应设置警报。
有关如何查看 Neptune 指标的信息，请参阅 使用亚马逊监控 Neptune CloudWatch。
以下是首先要查看的最重要指标：
BufferCacheHitRatio – 缓冲区缓存满足的请求的百分比。缓存未命中会给查询执行带来显著的延迟。如果缓存命中率低于 99.9%，并且您的应用程序存在延迟问题，请考虑升级实例类型以在内存中缓存更多数据。
CPU 利用率 – 使用的计算机处理容量的百分比。根据您的查询性能目标，高 CPU 消耗值可能是正常情况。
可释放内存 – 数据库实例上可用的 RAM 量（以 MB 为单位）。Neptune 有自己的内存管理器，因此该指标可能低于您的预期。可以很好地指示您应考虑将实例类升级到具有更多 RAM 的实例类的迹象是，查询经常引发内存不足异常。
对于 CPU 和内存指标，监控选项卡中的红线指标标记为 75%。如果实例内存消耗频繁越过红线，请检查您的工作负载并考虑升级实例以改进查询性能。
优化 Neptune 查询的最佳实践
提高 Neptune 性能的最佳方式之一是优化最常使用和占用资源最多的查询，以降低其运行成本。
有关如何调整 Gremlin 查询的信息，请参阅Gremlin 查询提示和调整 Gremlin 查询。有关如何调整 SPARQL 查询的信息，请参阅 SPARQL 查询提示。
跨只读副本的负载均衡
读取器终端节点轮询路由的运行方式是更改 DNS 条目指向的主机。客户端必须创建一个新的连接并解析 DNS 记录，才能获取与新只读副本的连接，因为 WebSocket 连接通常会长时间保持活动状态。
要为连续请求获取不同的只读副本，请确保您的客户端在每次连接时都会解析 DNS 条目。这可能需要关闭连接并重新连接到读取器终端节点。
您还可以通过显式连接到实例终端节点来跨只读副本对请求进行负载均载。
使用较大的临时实例加快加载速度
实例的大小越大，您的加载性能越高。如果您没有使用较大的实例类型，但希望提高加载速度，则可以先使用较大的实例进行加载然后删除它。
注意
以下过程是针对新集群的。如果您目前已经有一个集群，则可以添加一个新的较大实例，然后将其提升为新的主数据库实例。
使用较大的实例大小加载数据
使用单个
r5.12xlarge实例创建集群。此实例是主数据库实例。-
创建大小相同 (
r5.12xlarge) 的一个或多个只读副本。您可以创建大小较小的只读副本，但如果它们的大小不足以跟上主实例的写入速度，则可能必须频繁地重启。由此产生的停机时间会大大降低性能。
在批量加载程序命令中，加入
“parallelism” : “OVERSUBSCRIBE”以告知 Neptune 使用所有可用的 CPU 资源进行加载（请参阅Neptune 加载程序请求参数）。然后，加载操作将在 I/O 允许的范围内以最快的速度执行，这通常需要 60-70% 的 CPU 资源。使用 Neptune 加载程序加载您的数据。加载任务在主数据库实例上运行。
数据完成加载后，请务必将集群中的所有实例缩减为相同的实例类型，以避免额外费用和重复重启问题（请参阅避免使用不同的实例大小）。
通过失效转移到只读副本来调整写入器实例的大小
调整数据库集群中实例（包括写入器实例）大小的最佳方法是创建或修改只读副本实例，使其具有所需的大小，然后故意失效转移到该只读副本。您的应用程序看到的停机时间只是更改写入器的 IP 地址所需的时间，大约为 3 到 5 秒。
您用来故意将当前写入器实例失效转移到只读副本实例的 Neptune 管理 API 是 FailoverDBCluster。如果您使用的是 Gremlin Java 客户端，则可能需要在失效转移后创建一个新的客户端对象来获取新的 IP 地址，如此处所述。
请务必将所有实例更改为相同的大小，这样可以避免重复重启的循环，如下所述。
数据预提取任务中断错误后重试上传
当您使用批量加载程序将数据加载到 Neptune 时，有时可能会出现 LOAD_FAILED 状态，在对某个请求的响应中报告 PARSING_ERROR 和 Data prefetch
task interrupted 消息，以要求提供详细信息，如下所示：
"errorLogs" : [ { "errorCode" : "PARSING_ERROR", "errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed", "fileName" : "s3://some-source-bucket/some-source-file", "recordNum" : 0 } ]
如果遇到此错误，只需重试批量上传请求。
在发生临时中断时会出现此错误，这种中断一般不是由您的请求或数据导致的，并且通常可以通过再次运行批量上传请求加以解决。
如果您使用的是默认设置，即 "mode":"AUTO" 和 "failOnError":"TRUE"，则在发生中断时，加载程序会跳过已经成功加载的文件，并继续加载尚未加载的文件。