Amazon Neptune 基本操作指导 - Amazon Neptune
避免使用不同的实例大小避免批量加载重启如果您有很多谓词避免长时间运行的事务优化查询负载均衡使用临时实例调整实例大小任务中断错误

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

Amazon Neptune 基本操作指导

以下是使用 Neptune 时您应遵循的基本操作指导。

  • 了解 Neptune 数据库实例，以便您可以根据自己的性能和用例要求适当调整其大小。请参阅 Amazon Neptune 数据库集群和实例。

  • 监控您的 CPU 和内存使用情况。这有助于您了解何时迁移到具有更大 CPU 或内存容量的数据库实例类，以实现您所需的查询性能。您可以将 Amazon 设置 CloudWatch 为在使用模式发生变化或接近部署容量时通知您。这样做可以帮助您维护系统性能和可用性。有关详细信息，请参阅 监控实例 和 监控 Neptune。

    由于 Neptune 具有自己的内存管理器，即使 CPU 使用率较高，相对较低的内存使用率也是正常的。执行查询时遇到 out-of-memory异常是需要增加可用内存的最佳指标。

  • 启用自动备份并设置备份时段，使备份在便利的时段进行。

  • 测试您的数据库实例的故障转移，以了解对于您的使用案例而言，该过程需要多长时间。它还有助于确保访问您数据库实例的应用程序在故障转移之后可以自动连接到新数据库实例。

  • 如果可能，请在同一区域和 VPC 中运行您的客户端和 Neptune 集群，因为使用 VPC 对等连接的跨区域连接可能会导致查询响应时间的延迟。对于几个毫秒的查询响应，需要将客户端和 Neptune 集群保留在同一个区域和 VPC 中。

  • 在创建只读副本实例时，该实例至少应与主写入器实例一样大。这有助于阻止复制滞后，并避免副本重新启动。请参阅 避免在集群中使用不同的实例类。

  • 在升级到新的主要引擎版本之前，请务必在升级之前在其上测试您的应用程序。为此，您可以克隆数据库集群，使克隆集群运行新的引擎版本，然后在克隆上测试您的应用程序。

  • 为了便于进行故障转移，理想情况下，所有实例的大小应相同。

主题

避免在集群中使用不同的实例类

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

重要

为避免复制滞后导致重复重启，请配置您的数据库集群，使所有实例具有相同的实例类（大小）。

您可以使用 Amazon 中的ClusterReplicaLag指标查看数据库集群中的写入器实例（主实例）和读取器之间的延迟 CloudWatch。VolumeWriteIOPs 指标还允许您检测集群中可能造成复制滞后的写入活动突发情况。

避免在批量加载期间重复重启

如果您在批量加载期间由于复制滞后而经历了重复重启只读副本的循环，则您的副本可能无法跟上数据库集群中写入器的速度。

要么将读取器扩展到比写入器大，要么在批量加载期间暂时将它们移除，然后在完成后重新创建。

如果您的谓词数量很多，则启用 OSGP 索引

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

在这种情况下，您可以通过启用 OSGP 索引来提高性能。请参阅 OSGP 索引。

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

长时间运行的事务（无论是只读事务还是读写事务）可能导致以下类型的意外问题：

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

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

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

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

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

优化 Neptune 查询的最佳实践

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

有关如何调整 Gremlin 查询的信息，请参阅Gremlin 查询提示和调整 Gremlin 查询。有关如何调整 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 地址，如此处所述。

请务必将所有实例更改为相同的大小，这样可以避免重复重启的循环，如下所述。

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

当您使用批量加载程序将数据加载到 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://amzn-s3-demo-bucket/some-source-file",
    "recordNum" : 0
  }
]

如果遇到此错误，只需重试批量上传请求。

在发生临时中断时会出现此错误，这种中断一般不是由您的请求或数据导致的，并且通常可以通过再次运行批量上传请求加以解决。

如果您使用的是默认设置，即 "mode":"AUTO" 和 "failOnError":"TRUE"，则在发生中断时，加载程序会跳过已经成功加载的文件，并继续加载尚未加载的文件。