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

的操作最佳实践 ISVs

本节中的许多指南都是适用于所有客户的最佳实践，但它们对它们具有更重要的意义 ISVs。

使用最新版本更新你的 Neptune 集群

在 Amazon Neptune 发行说明中，您可以看到每个版本都带来了许多错误修复、性能改进和新功能。尽量让你的 Neptune 集群保持最新版本。

如果您在工作负载中发现了以前未被发现的错误，并且您的集群使用的是最新版本，Neptune 工程师可以为您的集群创建私有补丁（如果需要并且您想要的话）。该补丁可以桥接到下一个版本，届时该修复程序将正式推出。要帮助将集群更新到最新版本，请使用 Nep tune Blu e/Green 解决方案。

使用增量而不是删除和替换进行数据摄取

您可以使用多种技术将数据摄取或写入到 Neptune。许多客户试图通过每次收到数据源更改时删除并重新插入图表来简化数据摄取。他们可能会为每个节点添加一个last-modified属性，并定期扫描自某个指定日期以来未修改过的节点，然后将其删除。虽然这些技术简化了数据摄取过程，但它们会对您的 Neptune 集群产生长期的运行状况和可扩展性影响。

首先，Neptune 使用字符串的字典编码。除非您明确指定节点和边 IDs 的值，否则 Neptune 会生成一个以 ID 字符串表示的 GUID，并将该字符串存储在字典中。如果您经常删除和添加对象，则自动生成的对象 IDs 会导致字典膨胀。

其次，Neptune 向上扩展，最大每秒可摄取大约 120 K 个物体。如果您不断删除和添加对象，则会将大量带宽消耗在基本未更改的对象上。这限制了你可以在集群上托管的租户数量，需要在集群中使用更大的写入器实例，并且需要更多的 I/O 操作。所有这些因素都会增加您的成本。

我们强烈建议您开发一种方法来计算已更改内容的真实增量，而不是使用删除和添加方法。但是，有些数据源不利于此（例如，返回当前状态的 API 调用，或者无法准确跟踪更改内容的事件）。如果您的原始数据源不利于识别更改，请使用提取、转换和加载 (ETL) 过程来计算增量。例如，您可以以 Parquet 格式维护以前每次数据捕获的快照，用于 AWS Glue 计算这些快照之间的差异，然后仅将差异推送到 Neptune。

建模 Neptune 的成本将如何随着租户的变化而变化

无论您使用孤岛、池还是混合模式，您的云成本都将随着租户的规模而扩展。与并发连接较少的租户相比，需要更多并发连接的租户需要更大的实例或更多的只读副本。这同样适用于需要更快地摄取数据的租户。

Neptune 集群成本的三个组成部分是实例大小（和数量）、数据大小（GB-月）和 I/O 操作（每百万个）。虽然这些成本通常因工作负载而异，但它们会随着大小和数据量而扩展，但可以通过使用 AWS 工具来衡量。根据租户规模的关键指标，包括租户规模随时间的变化情况，跟踪和了解规模经济。如果 I/O 费用的不可预测性影响了利润，请考虑选择 Neptune I/O 优化存储，以获得更可预测的成本。

根据客户需求扩展您的集群

对于正确调整您的 Neptune 实例大小，没有久经考验或真实的公式。Nep tune 文档提供了指导，但变量太多，无法推荐直接映射。这些变量包括但不限于以下内容：

计划测试以确定您的工作负载和租户配置文件的最佳规模。一般而言，我们建议使用预配置实例，以提高成本效益和可预测性。如果您的客户体验目标优先考虑最佳扩展而不是成本，请考虑使用 Neptune Serverless 实例来确保无论工作负载如何波动都能获得更一致的体验。

如果您的租户读取工作负载的峰值和低谷变化很大，请将 Neptune Serverless 实例与 Neptune 自动缩放结合使用。  新的只读副本在初始化后通常需要 10-15 分钟才能上线。这意味着仅靠自动缩放可以应对长时间的流量变化，但这还不足以应对快速变化的活动峰值。通过将 Neptune Serverless 和 Neptune 自动缩放相结合，您可以向上或向下扩展实例，也可以缩小只读副本的数量。

如果您的租户的工作负载配置文件或服务级别协议（SLAs）有很大不同，请考虑使用自定义终端节点和专用只读副本将流量引导到针对该流量进行了优化的实例。优化可以包括不同的实例大小、特定的查询模式或预热缓冲区缓存。