`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`是更灵活的选择。