大规模使用转换

转换将现有的 Elasticsearch 索引转换为汇总索引，这为新的见解和分析提供了机会。转换执行的搜索和索引操作使用标准的 Elasticsearch 功能，因此，大规模使用 Elasticsearch 的类似注意事项通常适用于转换。如果您遇到性能问题，请首先确定瓶颈区域（搜索、索引、处理或存储），然后查看本指南中的相关注意事项以提高性能。了解转换的工作原理也很有帮助，因为不同的注意事项适用于转换是以连续模式还是以批处理模式运行。

在本指南中，您将学习如何

前提条件

这些指南假设您有一个想要调整的转换，并且您已经熟悉

以下注意事项不是按顺序排列的 - 数字有助于在列表项之间导航；您可以按任何顺序对其中一个或多个采取操作。大多数建议适用于连续和批处理转换。如果列表项仅适用于一种转换类型，则会在描述中突出显示此例外情况。

每个建议标题末尾括号中的关键字表示可以通过遵循给定的建议来改进的瓶颈区域。

为了优化转换性能，首先要确定完成最多工作的区域。Kibana 中 Transforms 页面的 Stats 界面包含涵盖三个主要区域的信息：索引、搜索和处理时间（或者，您可以使用 转换统计 API）。例如，如果结果显示大部分时间都花在搜索上，则应优先优化转换的搜索查询。转换还具有 Rally 支持，如果需要，可以使用它对转换配置进行性能检查。如果您优化了关键因素，但仍然遇到性能问题，您可能还需要考虑改进硬件。

在连续转换中，frequency 配置选项设置检查源索引中更改的间隔。如果检测到更改，则会搜索源数据并将更改应用于目标索引。根据您的用例，您可能希望降低应用更改的频率。通过将 frequency 设置为更高的值（最大为一小时），可以将工作负载随时间分散，但代价是数据更新频率降低。

根据目标索引的大小，您可以考虑增加其分片计数。转换在创建目标索引时默认使用一个分片。要覆盖索引设置，请在启动转换之前创建目标索引。有关分片数量如何影响可扩展性和弹性的更多信息，请参阅 为生产做好准备。

如果您已定义转换源索引 query，请确保它尽可能高效。使用 Kibana 中 Dev Tools 下的 Search Profiler 获取有关搜索请求中各个组件执行的详细计时信息。或者，您可以使用 Profile。结果可以让您深入了解搜索请求如何在底层执行，以便您可以了解某些请求速度缓慢的原因，并采取措施改进它们。

转换执行标准的 Elasticsearch 搜索请求。编写 Elasticsearch 查询的方法有很多种，其中一些方法比其他方法更有效。请参阅 调整搜索速度，了解有关 Elasticsearch 性能调整的更多信息。

假设您的连续转换配置为按 IP 分组并计算 bytes_sent 的总和。对于每个检查点，连续转换都会检测自上一个检查点以来源数据中的更改，从而识别已摄取新数据的 IP。然后，它执行第二次搜索，针对这组 IP 进行筛选，以计算总的 bytes_sent。如果第二次搜索匹配许多分片，则这可能会占用大量资源。请考虑限制源索引模式和查询将匹配的范围。

要限制访问哪些历史索引，请排除某些层（例如 "must_not": { "terms": { "_tier": [ "data_frozen", "data_cold" ] } } 和/或在源查询中使用绝对时间值作为日期范围筛选器（例如，大于 2024-01-01T00:00:00）。如果您使用相对时间值（例如，gte now-30d/d），请确保应用日期舍入以利用查询缓存，并确保相对时间远大于 frequency 或 time.sync.delay 或日期直方图存储桶的最大值，否则可能会遗漏数据。不要使用小于日期值的日期筛选器（例如，lt：小于或 lte：小于或等于），因为这与每个检查点执行时应用的逻辑冲突，并且可能会遗漏数据。

请考虑在索引名称中使用 日期数学，以减少查询中要解析的索引数量。在索引名称中添加日期模式（例如，yyyy-MM-dd）并使用它将查询限制为特定日期。下面的示例仅查询昨天和今天的索引

  "source": {
    "index": [
        "<mydata-{now/d-1d{yyyy-MM-dd}}*>",
        "<mydata-{now/d{yyyy-MM-dd}}*>"
    ]
  },

没有一种适用于所有情况的分片策略。在一个环境中工作的策略可能在另一个环境中无法扩展。良好的分片策略必须考虑您的基础设施、用例和性能预期。

分片太少可能意味着无法实现分配工作负载的好处；但是，分片太多可能会影响您的集群运行状况。要了解有关调整分片大小的更多信息，请阅读此指南。

max_page_search_size 转换配置选项定义每个搜索请求返回的存储桶数。默认值为 500。如果增加此值，您将获得更好的吞吐量，但代价是更高的延迟和内存使用率。

此参数的理想值高度依赖于您的用例。如果您的转换执行内存密集型聚合（例如，基数或百分位数），则增加 max_page_search_size 需要更多可用内存。如果超出内存限制，则会发生断路器异常。

运行时字段和脚本字段不是索引字段；它们的值仅在搜索时提取或计算。虽然这些字段在您访问数据的方式上提供了灵活性，但它们会增加搜索时的性能成本。如果使用运行时字段或脚本字段的转换性能令人担忧，您可能需要考虑改用索引字段。出于性能原因，我们不建议使用运行时字段作为同步连续转换的时间字段。

索引排序使您可以按特定顺序将文档存储在磁盘上，这可以提高查询效率。理想的排序逻辑取决于您的用例，但经验法则是按降序（高基数到低基数）对字段进行排序，从基于时间的字段开始。索引排序只能在索引创建时定义一次。如果您要用作源的索引上还没有索引排序，请考虑将其重新索引到新的、排序的索引。

_source 字段包含在索引时传递的原始 JSON 文档主体。_source 字段本身未被索引（因此不可搜索），但它仍然存储在索引中并会产生存储开销。如果您有较大的目标索引，请考虑禁用 _source 以节省存储空间。禁用 _source 只能在索引创建期间进行。