我们通过避免(深度)递归,改进了具有同步处理器的管道的管道执行逻辑。在我们模拟日志用例的夜间基准测试中,这导致花费在接收管道上的CPU时间减少了10%,总体接收速度提高了3%。
摄取管道有一种机制来防止它们处理的记录中出现循环引用,因此它们是可序列化的。在此更改之前,此检查是在每次脚本处理器执行后执行的,可忽略。
由于此检查,脚本处理器配置为
"source": """
def x = ctx;
ctx.x = x;
"""
…would error with "type" : "illegal_argument_exception", "reason" : "Iterable object is self-referencing itself (ingest script)"
.
如果脚本处理器也有
"ignore_failure" true
…然后,在尝试序列化结果事件时,处理线程实际上会从不可恢复的StackOverflowerError崩溃。
现在,每个管道执行一次此检查,以纠正堆栈溢出错误的可能性。还有一些副作用:
我们在8.3中引入了一个新的问答自然语言处理任务。此任务从更大的上下文中提取回答特定问题的相关部分。这特别适用于针对大型文档的搜索请求。你可以在下面看到一个从一篇关于塔桥的大型维基文章中提取答案的示例。
度量数据通常可以由几个名称中带有点的字段组成,这些字段共享公共前缀,如以下示例所示:
{
"metrics.time" : 10,
"metrics.time.min" : 1,
"metrics.time.max" : 500
}
这种格式会导致映射冲突,就像度量一样。时间持有一个值,但它也需要映射为对象,以持有最小和最大叶字段。
引入了一个名为subobjects的新对象映射参数,该参数默认为true,用于保留字段名称中的点。子对象设置为false的对象只能保存叶子子字段,而不能保存其他对象。以下示例显示了如何在metrics对象的映射中进行配置:
{
"mappings": {
"properties" : {
"metrics" : {
"type" : "object",
"subobjects" : false
}
}
}
}
通过这种配置,度量的任何子级都将不变地映射,而不会将字段名中的点扩展到相应的对象结构。这使得存储上述指标文档成为可能。
Elasticsearch对先前主要版本中创建的索引具有完全的查询和写入支持。如果您在Elasticsearch版本5或6中创建了索引,现在可以使用存档功能导入和查询这些索引。由于法规遵从性或监管原因、偶尔的回溯或调查,或为了使部分数据重新水化,归档功能提供了对较旧数据的较慢只读访问。对数据的访问预计不太频繁,因此可能在性能和查询能力有限的情况下发生。
现在可以在变换中使用范围聚合。Transforms不支持多bucket聚合,但此限制已不存在。
使用地理网格查询,您现在可以以本机方式返回与特定地理块重叠的所有文档。由于Elasticsearch可以为您重建几何体或空间簇的实际边界,因此无需重建几何体或空间簇的实际边界,从而节省时间并降低复杂性。当几何体分布在瓷砖上时(如足球或足球上),这尤其有用。虽然六边形瓷砖沿球体排列,但计算每个瓷砖的边界并不简单。
GET /example/_search
{
"query": {
"geo_grid" :{
"location" : {
"geotile" : "6/32/22"
}
}
}
}
地理网格查询也有助于确定包容真实性的单一来源。使用地理网格查询,您可以精确匹配Elasticsearch的相交测试。例如,如果客户端在运行相应聚合时,网格单元的边界精度高于(或低于)Elasticsearch使用的精度,则包含检查可能略有不同。该侧根据客户机和Elasticsearch之间的投影/基准差消除任何断开连接。