本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 性能效率支柱
Well-Architect AWS ed Framework 的[性能效率支柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/performance-efficiency.html)侧重于如何在摄取或查询数据时优化性能。性能优化是一个循序渐进的持续过程，包括以下内容：
+ 确认业务需求
+ 衡量工作负载性能
+ 识别表现不佳的组件
+ 调整组件以满足您的业务需求
性能效率支柱提供了可以帮助您选择高性能数据模型的指导方针。性能效率支柱包括查询和写入优化最佳实践。
绩效效率支柱侧重于以下关键领域：
+ Influx 数据建模和查询优化
+ 写入优化
## Influx 数据建模和查询优化
设计有效的架构对于优化InfluxDB中时间序列数据的性能和查询功能至关重要。首先选择正确的标签和字段。InfluxDB 为标签编制索引，因此查询引擎无需扫描测量中的每条记录即可找到标签值。这意味着查询标签比查询字段更高效。为了压缩和存储数据，存储引擎按系列键对字段值进行分组，然后按时间对这些字段值进行排序。系列密钥由度量、标签键和值以及字段键定义。有关数据设计的更多信息，请参阅 [InfluxDB 文档](https://docs.influxdata.com/influxdb/v2/reference/key-concepts/data-elements/)。
存储引擎使用时间结构化合并树 (TSM) 数据格式。有关 TSM 数据格式的更多信息，请参阅 [InfluxDB 文档](https://docs.influxdata.com/influxdb/v2/reference/internals/storage-engine/#time-structured-merge-tree-tsm)。
想象一下，您正在收集数据（`timestamp``host_id``region`、`cpu`、、`memory`、`network_in_bytes`、`network_out_bytes`、、`disk_io`），作为 DevOps 用例的一部分。标签（包括记录时间戳）提供了背景信息，以帮助识别记录的谁、内容、时间和地点。标签用于组织和分类数据，以及筛选作为查询一部分的数据。
`host_id`和`region`标签是组织和分类 DevOps 用例的理想标签。这些列有助于筛选特定主机的数据或根据区域列运行分析。
度量为对数据进行数学计算（例如计算总数、平均值和变化率差异）和定量分析提供了基础。因此，`cpu`、`memory`、`network_in_bytes``network_out_bytes`、并`disk_io`捕获与随着时间的推移 DevOps 而变化的重要指标。您可以使用这些指标来执行各种分析，例如计算不同主机的 CPU 和内存。您可以使用这些指标值来做出数据驱动的决策，以帮助避免生产中断和执行基础设施规划。
基数是唯一标签值的组合。尽量降低基数。如果您的应用程序需要每个数据点的唯一标识符，请使用字段值而不是标签值。这将显著改善查询延迟。良好的架构设计可以防止高序列基数，从而提高查询的性能。如果您注意到数据读取和写入速度变慢，或者您想了解基数如何影响性能，请参阅 InfluxDB 的 [Timestream 文档](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-getting-started-security-best-practices)。
如果您的应用程序发出 JSON 对象，请将其转换为单个列（标签或字段），然后将这些列加载到 InfluxDB 中。InfluxDB 专为时间序列数据而设计，因此使用单独的列组织数据是充分利用该服务功能的最佳实践。
一个 InfluxDB v2.7 OSS 实例支持在所有组织中主动写入或查询大约 20 个 InfluxDB 存储桶。超过 20 个存储桶可能会对性能产生不利影响。有些 InfluxDB 配置选项有限制，有些选项可以根据自己的用例进行配置。在测试阶段，根据应用程序工作负载验证配置。数据保留是在存储桶级别配置的，因此具有不同数据保留要求的数据应存储在不同的存储桶中。有关配置选项的更多信息，请参阅 [InfluxDB 的 Timestream](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-db-connecting.html#timestream-for-influx-parameter-groups) 文档。
将数据存储在标签值或字段值中，而不是存储在标签键、字段键或测量值中。如果您将架构设计为将数据存储在标签和字段值中，则您的查询将更易于编写且效率更高。有关数据建模的更多最佳实践，[请参阅性能设计](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-getting-started-security-best-practices-design-for-performance)。
使用 [InfluxDB任务](https://docs.influxdata.com/influxdb/cloud/process-data/get-started/)来预聚合数据，将数据加载到不同的测量值或存储桶中，并从中生成用于仪表板和可视化的数据。
InfluxDB OSS 公开了一个`/metrics`[端点，该端点](https://docs.influxdata.com/influxdb/v2/reference/internals/metrics/)返回以 Promethe**** us 纯文本公开格式格式格式格式的性能、资源和使用情况指标。使用 InfluxDB 模板设置[监控和警报](https://docs.influxdata.com/influxdb/v2/monitor-alert/templates/)，以主动检测问题，例如高查询延迟、写入吞吐量下降或资源使用高峰。
InfluxDB 的时间流提供 Influx IO 内含存储。选择适当的 IOPS 大小可以显著加快查询执行速度。这对于需要扫描大量数据或处理大量请求的查询特别有用。在某些情况下，可能需要将扩展实例和增强 IOPS 结合起来才能实现所需的性能改进。
我们建议匹配开发环境和生产环境（实例类别、存储类型、配置）。在进入生产环境之前，在较低的环境中测试每个版本的更改。在 Influx IO Included 存储卷上，InfluxDB 的 Timestream 提供了三个存储层，这些存储层已预先配置了最佳 IOPS（3,000、12,000、16,000）和不同类型的工作负载所需的吞吐量。大多数用例需要的 IOPS 不到 3,000。仅当性能测试表明需要高 IOPS 时，才选择 12,000 或 16,000。有关更多信息，请参阅 InfluxDB 的 Timestream 文档中的[设置部分](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-dbi-setting-up)。
## 优化写入
为了优化对 InfluxDB 的写入，我们建议每个请求以 5,000 行线路协议为单位批量写入数据，以最大限度地减少网络开销。为了获得更好的性能，请在写入数据点之前按字典顺序对标签进行排序。对时间戳使用尽可能粗略的时间精度，而不是纳秒，也可以提高性能。启用 gzip 压缩是加快写入速度和减少网络带宽的另一种方法。在`telegraf.conf`文件的`influxdb_v2`输出插件配置中，将`content_encoding`选项设置为`gzip`。实施这些优化可以显著提高向InfluxDB写入数据的性能和效率。如需了解更多 InfluxDB 写入最佳实践，请参阅[优化对 InfluxDB 的写入。](https://docs.influxdata.com/influxdb/v2/write-data/best-practices/optimize-writes/)
InfluxDB 的写入性能通常与可用的 IOPS 密切相关。写入数据时，InfluxDB 需要执行大量的 I/O 操作来存储数据。当你提高 IOPS 时，InfluxDB 每秒可以处理更多的写入。