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

# 成本优化支柱
<a name="cost-optimization"></a>

Well-Architecte AWS d Framework [的成本优化支柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html)侧重于避免不必要的成本，并以成本优化的方式构建架构。以下建议可以帮助您满足适用于 InfluxDB 的 Amazon Timestream 的成本优化设计原则和架构最佳实践。

成本优化支柱侧重于以下关键领域：
+ 了解您的用例的要求和成本
+ 在选择资源时要注意成本
+ 在不超支的情况下进行扩展以满足业务需求
+ 调整数据存储和传输的大小

## 了解您的用例的要求和成本
<a name="requirements-costs"></a>

在以下用例中，我们建议不要在 InfluxDB 上使用 Timestream：
+ 如果你的数据模型包含关系数据，那么 InfluxDB 的 Timestream 不是正确的解决方案。
+ 如果您无法在查询中使用时间过滤器，Influx 将扫描所有系列，这会降低效率。

## 在选择资源时要注意成本
<a name="select-resources"></a>

[InfluxDB 实例](https://aws.amazon.com/timestream/pricing/)的费用基于您的实例运行时间的小时费率。平均而言，实例占数据库运行总成本的85％ AWS，因此正确调整大小可能会带来显著的成本影响。调整实例大小的最佳方法是测试应用程序性能：
+ `CPUUtilization`和`MemoryUtilization`一直处于高位还是低位？
+ 价格和性能之间的平衡是什么？

实例成本呈线性扩展。`db.influx.2xlarge`实例的每小时成本是`db.influx.xlarge`实例的两倍，尽管它的资源分配也是实例的两倍。该`db.influx.16xlarge`实例的每小时成本是实例每小时成本的 `db.influx.xlarge` 16 倍。

估算工作负载在特定时间段（秒、分钟、小时或天）内的写入和读取次数。InfluxDB 实例的时间流支持每秒 5 万至超过 500,000 次写入和每秒 10-100 次查询 (QPS)，具体取决于实例类型。例如，`db.influx.2xlarge`通常每秒最多支持 150,000 次写入和大约 25 个 QPS。借助高效的数据模型和高效的查询，它可以超越该性能。如果您的要求因一天、一周或一个月的时间而异，则可以通过执行以下操作来安排向上和向下扩展：
+ [创建和安排 AWS Lambda 函数](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-run-lambda-schedule.html)。
+ 使用自定义调度程序并运行 API 或 SDK，在缓冲时间内向[上和向下扩展](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-managing-modifying-db.html)。

## 在不超支的情况下进行扩展以满足业务需求
<a name="scaling"></a>

要使用适用于 InfluxDB 的 Timestream 进行入门级实验，你可以使用和。`db.influx.medium` `db.influx.large`这些实例足够大，足以让您在投资更大的实例之前获得使用 Timestream for InfluxDB 的经验。

`db.influx.medium`和`db.influx.large`实例适用于低成本的开发环境。但是，它们具有较小的内存（8 GiB 和 16 GiB），更少的 v（CPUs 1 vCPU 和 2 vCPUs），网络性能最高仅为 10 GB。并非所有工作负载都适用于这些实例类别。监控`CPUUtilization`和`MemoryUtilization`，并根据需要向上或向下扩展。内存与 vCPU 之间通常具有一致的比率。db.influx 实例类的 memory-to-vCPU比率类似于 Amazon EC2 r7g 实例类。我们强烈建议在投入生产之前运行 end-to-end性能或负载测试。

高效的数据建模、批量写入和优化的查询需要更少的内存和计算使用量。当需要较少的资源时，您可以使用较小的实例。

## 调整数据存储和传输的大小
<a name="right-sizing"></a>

要存储数据，请使用以下最佳实践：
+ 在 InfluxDB 的时间流中仅存储时间序列数据。
+ 在 InfluxDB 存储桶上设置适当的保留期，以便删除早于保留期的数据，并定期自动压缩分片。有关更多信息，请参阅 [InfluxDB 文档](https://docs.influxdata.com/influxdb/v2/reference/internals/shards/#shard-compaction)。
+ 优化磁盘使用率，以备将来的写入。
+ 删除您的工作负载不需要的所有InfluxDB存储桶。InfluxDB 支持删除。如果符合您的用例，则可以按计划进行清理。

对于数据传输，我们建议将您的应用程序部署在与 InfluxDB 数据库实例的 Timestream AWS 区域 相同，以避免跨区域网络开销。可能还会收取数据传输费用。有关数据传输的更多信息，请参阅定[价页面](https://aws.amazon.com/timestream/pricing/)。