本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 成本优化支柱
Well-Architecte AWS d Framework [的成本优化支柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html)侧重于避免不必要的成本。以下建议可以帮助您满足 Amazon Neptune 的成本优化设计原则和架构最佳实践。
成本优化支柱侧重于以下关键领域：
+ 了解一段时间内的支出并控制资金分配
+ 选择类型和数量正确的资源
+ 在不超支的情况下进行扩展以满足业务需求
## 了解使用模式和所需的服务
如果您的数据模型具有清晰的图形结构，且您的查询需要探索关系并遍历多个跃点，则 Neptune 非常适合您的工作负载。图形数据库不适合以下模式：
+ 主要是单跳查询（考虑您的数据是否可以更好地表示为对象的属性）
+ JSON 或 BLOB 数据存储为属性
+ 对数据集进行聚合的查询，例如计算大量节点的数值属性之和
考虑将多个专用数据库一起用于特定的访问模式是否可以满足您的所有需求。例如：
+ 对于需要不那么频繁的复杂图形导航以及对单个节点属性进行高度并发检索的 API，最好使用一个或多个 Neptune、DynamoDB 或 Amazon DocumentDB 来呈现。
+ 关系数据库可以与 Neptune 共存以维持您现有的功能，但只能将 Neptune 用于在关系数据库中性能不佳和扩展性不佳的多跳遍历。
了解与 Neptune 交互和补充 Neptune 的服务关联的成本，包括：
+ Amazon Simple Storage Service（Amazon S3）存储成本，用于将数据文件批量加载到 Neptune 中
+ 用于插入或更新插入查询、读取查询和 Neptune 流处理的 Lambda 函数
+ 基于 Neptune 的 API 层用于与 Amazon API Gateway 中的客户端应用程序交互（而不是直接连接到数据库）或 AWS AppSync
+ AWS Glue 用于在 Neptune 之间传输数据和从海王星传输数据的作业
+ Amazon Kinesis 或 Amazon Managed Streaming for Apache Kafka（Amazon MSK）实例接收流数据，以近乎实时地将数据摄取到 Neptune。
+ AWS Database Migration Service 用于将关系数据迁移到 Neptune
+ Jupyter 笔记本和深度图库机器学习模型的 Amazon SageMaker Runtime 成本
## 选择资源时要注意成本
[Neptune 定价](https://aws.amazon.com/neptune/pricing/)基于每小时实例成本（或无服务器消耗的 Neptune 计算单元）、数据 I/O 和存储使用量。平均而言，实例占总成本的 85％，因此优化规模可能会带来显著的成本影响。调整实例大小的最佳方法是在各种实例上测试应用程序性能并比较以下因素：
+ 该`MainRequestQueuePendingRequests` CloudWatch 指标是否一直保持在接近零的低水平？
+ 该`BufferCacheHitRatio` CloudWatch 指标是否在大多数时间都保持在或高于 99.9%？
+ 实例成本和相关数据 I/O 成本的成本和性能曲线是什么？ 如果实例容量过小，需要频繁地将缓冲区缓存与存储交换，则数据读取成本可能会显著增加。在这些情况下，`BufferCacheHitRatio` 将会频繁下降。
实例成本随相同实例系列内的大小线性扩展。`db.r6i.2xlarge` 实例的每小时成本是 `db.r6i.xlarge` 实例的两倍，资源分配也是后者的两倍。`db.r6i.24xlarge` 实例的每小时成本是 `db.r6i.xlarge` 实例每小时成本的 24 倍。
估算您必须支持的并发查询数量。您可以拥有 0 到 15 个只读副本来处理只读查询。如果您的要求因一天、一周或一个月的时间而异，则可以使用多个较小的实例按计划进行扩展。实例上的每个 vCPU 都提供两个用于处理并发查询的线程。三个 `db.r6i.xlarge` 只读副本（每个副本有 4 个 vCPU）可以处理 24 个并发查询。
如果您的流量改为以每秒查询数（QPS）来衡量，则必须进行实验以确定查询的平均延迟。Neptune 集群每秒可以支持的查询数等于 `vCPU × 2 × (1 second/average query latency)`。例如，如果您有 4 个 vCPU，查询延迟为 100 毫秒（0.1 秒），则 `QPS = 4 × 2 × (1s/0.1s) = 80 queries per second`。
对于持续、稳定和可预测的工作负载，预调配实例比无服务器实例更便宜。当您的工作负载每天只需几小时即可达到非常高的使用率（例如，`db.r6i.4xlarge`），而一天中的其余时间几乎没有流量（例如，1 个 Neptune 计算单位）时，无服务器可提供优化成本的机会。使用一个可纵向扩展几小时然后再缩减的无服务器实例，比全天使用预调配 `db.r6i.4xlarge` 实例更便宜。
考虑升级到 Neptune 1.4.5.0 或更高版本，并利用`r8g`实例以比老一代实例（例如或）更低的成本实现更好的读取和写入吞吐量。`r7g` `r6g`有关更多信息，请参阅[使用 Amazon Neptune v1.4.5 的 G AWS raviton4 r8g 实例的写入查询性价比提高 4.7 倍](https://aws.amazon.com/blogs/database/4-7-times-better-write-query-price-performance-with-aws-graviton4-r8g-instances-using-amazon-neptune-v1-4-5/)（博客文章）。AWS
默认情况下，Neptune 集群是使用[标准存储](https://docs.aws.amazon.com/neptune/latest/userguide/storage-types.html)创建的（如果您使用控制台创建，则默认选择I/O-optimized storage). With I/O-optimized storage, you pay a slightly higher cost for storage and instances, but there are no I/O costs. This leads to more predictable recurring costs, but if your I/O usage is generally low, it may be more cost efficient to utilize standard storage. If you intend to load a lot of data initially, you can optimize cost by choosing I/O经过优化的存储，执行初始数据加载，然后切换到标准存储。存储类型仅影响计费模式，在 Neptune 数据库集群或实例配置中没有技术差异。您可以每 30 天更改一次存储类型。30 天后，查看您的 Neptune 详细费用，然后使用 Nept [une 定价页面](https://aws.amazon.com/neptune/pricing/)来计算使用优化后的费用是否会更高。I/O-optimized storage. If they would have been, continue to use standard storage, otherwise switch back to I/O
## 为您的工作负载选择最佳 Neptune 实例配置
如果您在 2025 年 7 月 15 日 AWS 账户 之前创建，则可以使用[AWS 免费套餐](https://aws.amazon.com/free/legacy/)进行 Neptune 的入门级实验。750 小时的 `db.t3.medium` 和 `db.t4g.medium` 实例免费使用时间足以让您很好地了解小规模下的 Neptune。在免费试用期结束后，您的集群仍将保留，但从那时起您将需要支付使用费用。
`db.t3.medium`和`db.t4g.medium`实例适用于不使用 OpenCypher、Graph Explorer 或各种生成式 AI 集成的低成本开发环境。这些实例的 RAM-to-vCPU比例 (2:1) 小于`R`系列实例 (8:1) 或`X`系列实例 (16:1)。这降低了比率，从而阻止了使用支持 OpenCypher 性能的 [DFE 引擎统计信息](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-dfe-statistics.html)、GenAI 集成（向 LLM 通报图形架构）和 Graph Explorer。使用`T`系列实例时，性能配置文件可能会有很大差异，特别是对于前面提到的工作负载。`OutOfMemoryExceptions`当查询在图表的很大一部分中导航时，这些实例还会增加出现的次数。要确定后一种情况是否可能受到影响，请检查`BufferCacheHitRatio` CloudWatch 指标。
我们强烈建议不要对`T`系列实例进行任何性能或负载测试，因为您可能会遇到不一致的结果，而这些结果并不代表生产环境。
当您的工作负载相当稳定且可预测时，预调配实例可为您提供最佳成本和性能组合。根据所需的请求并发性和查询复杂性选择实例大小。更高的并发性需要更多的 v CPUs。 查询复杂度越高，需要更多的 RAM。使用该`MainRequestQueuePendingRequests` CloudWatch 指标来确定前者的影响（大于零表示并发请求数多于可以处理的数量）。使用该`BufferCacheHitRatio` CloudWatch 指标来确定后者的影响。如果 RAM 使用率经常低于 99.9%，则表明 RAM 不足以容纳正在评估的图形的工作部分，从而导致更频繁地交换缓存。如果 R 系列实例提供了足够的并发性，但内存不足，请考虑尝试使用该`X`系列实例。
[Neptune 文档](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-serverless.html#neptune-serverless-uses)中描述了无服务器实例的理想使用案例。如果您不确定预配置还是无服务器最适合您，并且成本是您的主要考虑因素，请在无服务器中测试您的工作负载以确定 NCUs 使用的数量，并将预配置 () 与无服务器 (`N hours × hourly provisioned cost`) 的成本进行比较。`sum of NCUs × hourly cost per NCU`如果您不确定同等大小的预调配实例，则一个 NCU 相当于大约 2GB 的 RAM 以及关联的 vCPU 和网络。如果您的预配置实例来自该`r6i`系列，则该比率为每 8 GB RAM 1 个 vCPU，或者 NCUs 4 个，再加上关联的网络。[Amazon Neptune 定价计算器](https://pricingcalc.neptunedemos.com/)还提供比较，以帮助您确定最佳的成本配置。
在对主实例和副本实例使用无服务器时，请记住，升级层 0 和 1 中的只读副本将根据写 NCUs 入器实例进行扩展，以便在发生故障转移事件时可以正确扩展它们。根据您的哪个实例（写入器或读取器）接收的流量最多，为这些实例设置 NCU 限制。
在不需要集群全天候运行的环境中，可以考虑编写脚本，以便在不使用 Neptune 实例时将其关闭，并在需要使用之前重新启动它们。Neptune 实例将每 7 天自动重启一次，以确保应用所需的维护更新。如果您打算长时间关闭实例，请使用每周脚本再次将其关闭。
## 适当调整数据存储和传输的大小
更高效的查询（例如，需要触及图中较少节点、边和属性的查询）需要更少的 I/O 传输，并且由于需要的缓冲区缓存较少，因此有可能使用较小的实例。使用您的查询语言的 profile 或 explain 端点来优化查询，并考虑优化图表模型以提高查询性能。
Neptune 对大型字符串使用词典编码，该词典针对性能而非效率进行了优化。如果你的属性字符串很大 BLOBs、JSON 或者经常更改，可以考虑将它们存储在 Neptune 之外的亚马逊 S3、亚马逊 DynamoDB 或 Amazon DocumentDB 中，并且只在 Neptune 节点中存储引用。
在某些情况下，选择更大的实例大小可能更便宜。如果由于较低而导致 I/O 成本非常高`BufferCacheHitRatio`，则较大的缓冲区缓存可能会显著降低该成本。这是因为所有数据都将存放在缓存中，而不是经常从存储中交换并产生 I/O 传输速率。
Neptune 使用克隆 copy-on-write。在克隆以将图表拆分为多个分片时，不删除克隆集群上不需要的数据可能更有效，因为这将涉及创建新的数据页面，从而导致存储成本增加。克隆事件发生前未发生变化的数据将存在于两个集群之间共享的单个数据页面中，且仅对该单个副本收费。
请勿启用 OSGP 索引或使用 R5d 实例，除非您已测试确认它们对您的工作负载有重大影响。两者都是为极少发生的情况而设计的，它们可能会增加您的成本，而收益微乎其微或根本没有收益。