成本优化支柱

Well-Architecte AWS d Framework 的成本优化支柱侧重于避免不必要的成本，并以成本优化的方式构建架构。以下建议可以帮助您满足适用于 InfluxDB 的 Amazon Timestream 的成本优化设计原则和架构最佳实践。

成本优化支柱侧重于以下关键领域：

• 了解您的用例的要求和成本

• 在选择资源时要注意成本

• 在不超支的情况下进行扩展以满足业务需求

• 调整数据存储和传输的大小

了解您的用例的要求和成本

在以下用例中，我们建议不要在 InfluxDB 上使用 Timestream：

• 如果你的数据模型包含关系数据，那么 InfluxDB 的 Timestream 不是正确的解决方案。

• 如果您无法在查询中使用时间过滤器，Influx 将扫描所有系列，这会降低效率。

在选择资源时要注意成本

InfluxDB 实例的费用基于您的实例运行时间的小时费率。平均而言，实例占数据库运行总成本的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 函数。

• 使用自定义调度程序并运行 API 或 SDK，在缓冲时间内向上和向下扩展。

在不超支的情况下进行扩展以满足业务需求

要使用适用于 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性能或负载测试。

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

调整数据存储和传输的大小

要存储数据，请使用以下最佳实践：

• 在 InfluxDB 的时间流中仅存储时间序列数据。

• 在 InfluxDB 存储桶上设置适当的保留期，以便删除早于保留期的数据，并定期自动压缩分片。有关更多信息，请参阅 InfluxDB 文档。

• 优化磁盘使用率，以备将来的写入。

• 删除您的工作负载不需要的所有InfluxDB存储桶。InfluxDB 支持删除。如果符合您的用例，则可以按计划进行清理。

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