Amazon Neptune 基本操作指导方针 - Amazon Neptune
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

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 Relational Database Service) 资源的人员分配个人 IAM 账户。请勿使用Amazon帐户根用户来管理 Neptune 资源。为每个人(包括您自己)创建一个 IAM 用户。

  • 授予每位用户执行其职责所需的最小权限集。

  • 使用 IAM 组有效地管理适用于多个用户的权限。

  • 定期交替 IAM 凭证。

有关使用 IAM 访问 Neptune 资源的更多信息,请参阅。Amazon Neptune 中的安全性. 有关使用 IAM 的一般信息,请参阅Amazon Identity and Access ManagementIAM 最佳实践中的IAM 用户指南.

如果您的谓词数量很多,则启用 OSPG 索引

如果您的数据模型包含大量不同的谓词(大多数情况下超过千个),则可能会面临性能降低和更高的运营成本。

如果是这种情况,您可以通过启用OSPG 指数. 请参阅 OSGP 索引

尽可能避免长时间运行的事务

长时间运行的事务(只读或读写)可能会导致以下类型的意外问题:

在读取器实例上或具有并发写入的写入器实例上长时间运行的事务可能会导致大量不同版本的数据累积。这会给读取查询带来更高的延迟,这些查询会过滤掉大部分结果。

在某些情况下,数小时内累积的版本可能会导致新的写入受到限制。

如果实例重新启动,长时间运行的读写事务也可能导致问题。如果实例从维护事件或崩溃重新启动,则会回滚所有未提交的写入操作。此类撤消操作通常在后台运行,不会阻止实例恢复,但是任何与正在回滚的操作冲突的新写入操作都会失败。

例如,如果在上一次运行中断开连接后重试相同的查询,则在重新启动实例时可能会失败。

撤消操作所需的时间与所涉更改的大小成正比。

使用 Neptune 指标的最佳实践

要确定资源不足和其他常见瓶颈导致的性能问题,您可以监控可用于 Neptune Dabase 集群的指标。

定期监控性能指标以收集有关各种时间范围内的平均值、最大值和最小值数据。这可帮助确定性能下降的时间。使用此数据,您可以针对特定指标阈值设置 Amazon CloudWatch 警报,以便在达到这些阈值时向您发出警报。

设置新的数据库集群并让它在典型工作负载下运行时,尝试按一些不同的间隔(例如,一小时、二十四小时、一周、两周)来捕获所有性能指标的平均值、最大值和最小值。这将使您能够了解运行状况。这有助于将操作的峰值时间与非峰值时间进行比较。您随后可以利用这些信息确定性能何时降到标准水平以下,然后相应设置警报。

请参阅使用 Amazon CloudWatch 监控 Neptune以获取有关如何查看 Neptune 指标的信息。

以下是首先要查看的最重要指标:

  • BufferCacheHitRatio— 缓冲区缓存提供的请求的百分比。高速缓存未命中会给查询执行带来显著延迟。如果缓存命中率低于 99.9% 且延迟是您的应用程序的问题,请考虑升级实例类型以在内存中缓存更多数据。

  • CPU 使用率— 使用的计算机处理容量的百分比。根据您的查询性能目标,高 CPU 消耗值可能是正常情况。

  • 可释放内存— 数据库实例上可用的 RAM 量(以 MB 为单位)。Neptune 具有自己的内存管理器,所以此指标可能低于您的预期值。可以很好地指示您应考虑将实例类升级到具有更多 RAM 的实例类的迹象是,查询经常引发内存不足异常。

对于 CPU 和内存指标,监控选项卡中的红线指标标记为 75%。如果实例内存消耗频繁越过红线,请检查您的工作负载并考虑升级实例以改进查询性能。

优化 Neptune 查询的最佳实践

提高 Neptune 性能的最佳方式之一是优化最常使用和占用最多资源的查询,以降低其运行成本。

有关如何调整 Gramlin 查询的信息,请参阅。Grelin 查询提示优化 Grelin 查询. 有关如何调整 SPARQL 查询的信息,请参阅 SPARQL 查询提示

跨只读副本的负载均衡

读取器终端节点轮询路由的运行方式是更改 DNS 条目指向的主机。客户端必须创建一个新的连接并解析 DNS 记录,才能获取与新只读副本的连接,因为 WebSocket 连接通常会长时间保持活动状态。

要为连续请求获取不同的只读副本,请确保您的客户端在每次连接时都会解析 DNS 条目。这可能需要关闭连接并重新连接到读取器终端节点。

您还可以通过显式连接到实例终端节点来跨只读副本对请求进行负载均载。

使用较大的临时实例加快加载速度

实例的大小越大,您的加载性能越高。如果您没有使用较大的实例类型,但希望提高加载速度,则可以先使用较大的实例进行加载然后删除它。

注意

以下过程是针对新集群的。如果您目前已经有一个集群,则可以添加一个新的较大实例,然后将其提升为新的主数据库实例。

使用较大的实例大小加载数据

  1. 使用单个 r5.12xlarge 实例创建集群。此实例是主数据库实例。

  2. 创建一个或多个具有相同大小的只读副本(r5.12xlarge)。

    您可以使用较小的大小创建只读副本,但如果它们的大小不足以跟上主实例所做的写入操作,则可能需要频繁重新启动。由此产生的停机时间显著降低性能。

  3. 在批量加载器命令中,包含“parallelism” : “OVERSUBSCRIBE”来告诉 Neptune 使用所有可用的 CPU 资源进行加载(请参阅Neptune 加载程序请求参数)。然后,加载操作将按照 I/O 允许的速度进行,这通常需要 60-70% 的 CPU 资源。

  4. 使用 Neptune 加载程序加载您的数据。加载任务在主数据库实例上运行。

  5. 数据加载完成后,请务必将集群中的所有实例向下扩展到相同的实例类型,以避免额外费用和重复重新启动问题(请参阅避免不同的实例大小)。

通过故障切换到只读副本来调整写入器实例的大小

调整数据库集群(包括写入器实例)中实例大小的最佳方法是创建或修改只读副本实例,使其具有所需的大小,然后故意故障切换到该只读副本。您的应用程序看到的停机时间仅仅是更改写入程序 IP 地址所需的时间,该时间应为 3 到 5 秒左右。

用于故意将当前写入器实例故意转移到只读副本实例的 Neptune 管理 API 是FailoverDBCluster. 如果您使用的是 Gremlin Java 客户端,则可能需要在故障转移后创建一个新的客户端对象以获取新的 IP 地址,如上所述此处.

请确保将所有实例更改为相同大小,以避免重复重新启动的循环,如下所述。

避免集群中的不同实例类

当您的数据库集群包含不同类的实例时,可能会随着时间的推移而出现问题。最常见的问题是,由于复制滞后,小型读取器实例可能会进入重复重新启动的循环。如果读取器节点的数据库实例类配置比写入器数据库实例的配置弱,则更改量可能太大,读取器无法赶上。

重要

为避免复制延迟导致重复重新启动,请配置数据库集群,使所有实例具有相同的实例类(大小)。

您可以查看写入器实例(主实例)与数据库集群中的读取器之间的滞后,使用ClusterReplicaLag指标 Amazon CloudWatch 据。这些区域有:VolumeWriteIOPs度量还允许您检测群集中可能造成复制滞后的写入活动突发。

数据预取任务中断错误后重试上传

当您使用批量加载器将数据加载到 Neptune 时,LOAD_FAILED状态可能偶尔会导致,PARSING_ERRORData 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",则在发生中断时,加载程序会跳过已经成功加载的文件,并继续加载尚未加载的文件。