`script_fields`和`runtime_fields`都是 Elasticsearch 中用于动态计算字段值的功能，但它们在实现方式、应用场景和性能表现上存在显著区别。以下是两者的详细对比：
1.定义和应用场景
• `script_fields`：
• 定义：通过 Painless 脚本在查询阶段动态计算字段值。
• 应用场景：主要用于在查询结果中添加额外的计算字段，这些字段不会影响查询的执行逻辑。
• 示例：计算文档中多个字段的平均值，或基于字段值进行复杂计算。
• `runtime_fields`：
• 定义：在查询时动态定义字段，支持“读时模式”（Schema on Read），允许在查询时修改数据结构。
支持“读时模式”（Schema on Read）
• 读时模式（Schema on Read）：
• 在“读时模式”中，数据结构（即字段的定义）是在查询时动态解析和定义的，而不是在数据写入时预先定义。
• 这与传统的“写时模式”（Schema on Write）形成对比，在“写时模式”中，数据结构必须在索引阶段预先定义，且难以修改。
• 优点：• 灵活性：可以在查询时动态调整字段的定义，无需重新索引数据。
• 动态性：可以基于实时数据动态计算字段值，支持复杂的逻辑。
• 无需预定义：无需在索引阶段预先定义字段，减少了索引阶段的复杂性。
• 缺点：
• 性能开销：由于字段值是在查询时动态计算的，可能会增加查询的计算开销。
• 复杂性：脚本的编写和调试可能需要一定的技术能力。
• 应用场景：适用于需要在查询时动态添加字段、修改字段值，或基于这些字段进行过滤、排序和聚合。
• 示例：动态添加字段用于过滤、排序，或从其他索引中检索字段值（lookup runtime fields）。
2.执行阶段和性能
• `script_fields`：
• 执行阶段：在查询的fetch 阶段执行，即在文档被检索后才计算字段值。
• 性能影响：对查询性能的影响较小，但无法用于过滤、排序或聚合。
• `runtime_fields`：
• 执行阶段：从查询的开始阶段就参与计算，因此可以用于过滤、排序和聚合。
• 性能影响：由于在查询时动态计算，可能会对查询性能产生较大影响，尤其是在处理大量文档时。
3.索引和存储
• `script_fields`：
• 索引：不存储也不索引，仅在查询结果中返回。
• 存储：不占用额外的存储空间。
你的总结非常准确！`runtime_fields`是 Elasticsearch 中一个非常灵活的功能，它允许你在查询时动态定义和计算字段，而不需要在索引阶段预先存储这些字段的值。以下是对你总结的进一步详细解释：
---
1.不存储也不索引，但可以通过`fields`参数返回
• 不存储也不索引：
• `runtime_fields`是在查询时动态计算的，它们不会被存储在索引中，也不会被倒排索引（inverted index）。这意味着它们不会占用额外的磁盘空间，也不会影响索引的大小。
• 由于它们是动态计算的，每次查询时都会根据定义的脚本实时生成字段值。
• 可以通过`fields`参数返回：
• 尽管`runtime_fields`不存储，但你可以在查询结果中通过`fields`参数返回这些字段的值。这类似于`script_fields`的行为，但`runtime_fields`更灵活，因为它们可以用于过滤、排序和聚合。
示例：
```json
GET /myindex/_search
{
"query": {
"match_all": {}
},
"fields": ["runtime_field_name"]
}
```
---
2.不占用额外的存储空间，但可以动态添加到索引的映射中
• 不占用额外的存储空间：
• 由于`runtime_fields`是在查询时动态计算的，它们不会像普通字段那样占用磁盘空间。这使得`runtime_fields`非常适合处理临时或动态生成的数据，而不需要担心存储成本。
• 可以动态添加到索引的映射中：
• `runtime_fields`可以通过更新索引的映射（mapping）动态添加到索引中。这意味着你可以在不重新索引数据的情况下，随时添加新的字段定义。
• 这种动态性使得`runtime_fields`非常灵活，尤其是在处理动态数据结构或临时需求时。
示例：动态添加`runtime_field`
```json
PUT /myindex/_mapping
{
"runtime": {
"runtime_field_name": {
"type": "double",
"script": {
"source": "emit(doc['field1'].value + doc['field2'].value)"
}
}
}
}
```
---
对比：`runtime_fields`vs.普通字段 vs.`script_fields`
特性 `runtime_fields` 普通字段 `script_fields`
**存储** 不存储，不占用磁盘空间 存储，占用磁盘空间 不存储，不占用磁盘空间
**索引** 不索引，但可以动态添加到映射 索引，支持快速查询 不索引，仅在查询结果中返回
**动态性** 动态计算，支持过滤、排序、聚合 静态存储，适合快速查询 动态计算，仅支持查询结果
**性能** 查询时计算，可能影响性能 预存储，查询性能高 查询时计算，可能影响性能
**灵活性** 动态添加字段，无需重新索引 需要预先定义，难以修改 动态计算，适合简单逻辑
---
总结
• `runtime_fields`：
• 不存储也不索引，但可以通过`fields`参数返回。
• 不占用额外的存储空间，但可以动态添加到索引的映射中。
• 适合动态计算、过滤、排序和聚合，但可能影响查询性能。
• 普通字段：
• 存储并索引，适合快速查询。
• 需要预先定义，难以动态修改。
• `script_fields`：
• 不存储也不索引，仅在查询结果中返回。
• 适合简单的动态计算，但不支持过滤、排序和聚合。
通过合理选择`runtime_fields`、普通字段或`script_fields`，你可以根据具体需求优化 Elasticsearch 的查询性能和灵活性。
• `runtime_fields`：
• 索引：不存储也不索引，但可以通过`fields`参数返回。
• 存储：不占用额外的存储空间，但可以动态添加到索引的映射中。
4.灵活性和动态性
• `script_fields`：
• 灵活性：仅在查询时动态计算，无法用于过滤或排序。
• 动态性：适合简单的计算和装饰性字段。
• `runtime_fields`：
• 灵活性：可以在查询时动态定义，支持过滤、排序和聚合。
• 动态性：支持动态添加和删除字段，无需重新索引数据。
5.示例对比
使用`script_fields`：
```json
GET runtime_test/_search
{
"query": {
"match_all": {}
},
"script_fields": {
"avg": {
"script": {
"source": "(doc['participations.race1.time_secs'].value + doc['participations.race2.time_secs'].value + doc['participations.race3.time_secs'].value)/3;"
}
}
}
}
```
• 结果：返回每个文档的平均值，但无法用于过滤。
使用`runtime_fields`：
```json
PUT runtime_test/_mapping
{
"runtime": {
"times_average": {
"type": "double",
"script": {
"source": "emit((doc['participations.race1.time_secs'].value + doc['participations.race2.time_secs'].value + doc['participations.race3.time_secs'].value)/3);"
}
}
}
}
GET runtime_test/_search
{
"query": {
"range": {
"times_average": {
"gte": 100,
"lte": 200
}
}
}
}
```
• 结果：可以用于过滤、排序和聚合。
在 Elasticsearch 中，`runtime_fields`的一个关键特性是它们可以在查询时动态计算，并且可以像普通字段一样用于过滤、排序和聚合。这意味着你可以在查询中对动态计算的字段执行复杂的操作，而不需要预先在索引中存储这些字段的值。
让我们详细解释一下你的问题中的代码示例，以及`runtime_fields`如何支持过滤、排序和聚合。
---
示例代码
定义`runtime_field`
```json
PUT runtime_test/_mapping
{
"runtime": {
"times_average": {
"type": "double",
"script": {
"source": "emit((doc['participations.race1.time_secs'].value + doc['participations.race2.time_secs'].value + doc['participations.race3.time_secs'].value)/3);"
}
}
}
}
```
使用`runtime_field`进行查询
```json
GET runtime_test/_search
{
"query": {
"range": {
"times_average": {
"gte": 100,
"lte": 200
}
}
}
}
```
---
1.过滤（Filtering）
在查询中，`runtime_fields`可以像普通字段一样用于过滤操作。例如，上述查询中使用了`range`查询，对`times_average`字段进行了范围过滤：
• `gte: 100`表示只返回`times_average`大于或等于 100 的文档。
• `lte: 200`表示只返回`times_average`小于或等于 200 的文档。
这意味着你可以根据动态计算的字段值过滤文档，而不需要预先存储这些值。
---
2.排序（Sorting）
`runtime_fields`也可以用于排序。例如，你可以根据`times_average`字段对结果进行排序：
```json
GET runtime_test/_search
{
"query": {
"match_all": {}
},
"sort": [
{
"times_average": {
"order": "desc"
}
}
]
}
```
• 这个查询会根据`times_average`字段的值对文档进行降序排序。
• 由于`times_average`是动态计算的，排序操作会基于动态计算的结果进行。
---
3.聚合（Aggregation）
`runtime_fields`还可以用于聚合操作。例如，你可以计算`times_average`字段的平均值、最大值或最小值：
```json
GET runtime_test/_search
{
"size": 0,
"aggs": {
"avg_times_average": {
"avg": {
"field": "times_average"
}
},
"max_times_average": {
"max": {
"field": "times_average"
}
}
}
}
```
• 这个查询会计算`times_average`字段的平均值和最大值。
• 由于`times_average`是动态计算的，聚合操作会基于动态计算的结果进行。
---
为什么`runtime_fields`可以用于过滤、排序和聚合？
1. 动态计算：
• `runtime_fields`在查询时动态计算，计算结果会临时存储在内存中，因此可以像普通字段一样被查询引擎使用。
• 这种动态计算的方式允许你在查询时定义复杂的逻辑，而不需要预先存储这些字段的值。
2. 灵活性：
• 你可以根据需要动态添加或修改`runtime_fields`，而不需要重新索引数据。
• 这使得`runtime_fields`非常适合处理动态数据结构或临时需求。
3. 性能：
• 虽然`runtime_fields`的计算会增加查询的计算开销，但它们的灵活性和动态性使得它们在某些场景下非常有用。
• 对于复杂的查询逻辑，`runtime_fields`提供了一种高效的方式来实现。
---
总结
• 过滤：`runtime_fields`可以用于范围查询、匹配查询等过滤操作。
• 排序：可以基于`runtime_fields`的值对文档进行排序。
• 聚合：可以对`runtime_fields`进行聚合操作，如计算平均值、最大值等。
通过合理使用`runtime_fields`，你可以实现更灵活的查询逻辑，同时避免在索引阶段进行复杂的数据预处理。
总结
• 如果你需要在查询结果中添加简单的计算字段，且不希望影响查询性能，`script_fields`是一个不错的选择。
• 如果你需要动态定义字段，并希望这些字段支持过滤、排序和聚合，`runtime_fields`是更灵活的选择。
