Elasticsearch 字段膨胀不要怕,Flattened 类型解千愁!

Posted 铭毅天下

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Elasticsearch 字段膨胀不要怕,Flattened 类型解千愁!相关的知识,希望对你有一定的参考价值。

1、线上真实案例

球友问题:我记得您写过一篇关于建模字段膨胀的问题,对于比如request header response这种动态的对象,是怎么处理来着?

进一步反馈:决定升级es高版本了,Flattened  解千愁!主要我们这需求要把接口所有信息都保留,只能这样了。

2、Elasticsarch 字段膨胀

Elasticsearch Mapping 如果不做特殊设置,默认为 dynamic。dynamic 的本质就是:不加约束的动态添加字段。这样对某些日志场景,可能会产生大量的未知字段。字段如果持续激增,就会达到 Elasticsearch Mapping 层面的默认上限,对应设置和默认大小为:index.mapping.total_fields.limit:1000。

我们把这种非预期字段激增的现象或结果称为:字段膨胀

拿自己线上环境示例,说一下 dynamic 的副作用。在一个实际业务环境,混淆了检索和写入的语法,会导致将检索语句动态认定为新增 Mapping 字段。

当然,如果是非常复杂的大 bool 检索语句,会导致 Mapping 变得非常复杂甚至会出现字段膨胀的情况。

当然,可行的解决方案就是:dynamic 设置为 false,甚至更为严谨的推荐方式:将 dynamic 设置为 strict。

2.1 解决字段膨胀方案一:dynamic 设置为 false

dynamic 设置为 false 后,新来的非 mapping 预设字段数据可以写入,但是:不能被检索,仅支持 Get 获取文档的方式通过 _source 查看详情内容。

举例如下:

2.2 解决字段膨胀方案二:dynamic 设置为 strict

dynamic 一旦设置为:strict,会“阻止一切来犯之敌”,一切索引创建阶段指定的 Mapping 字段之外的字段名称都将会报错。

设置为 strict 后,再动态插入数据,会报错如下:

{
  "error" : {
    "root_cause" : [
      {
        "type" : "strict_dynamic_mapping_exception",
        "reason" : "mapping set to strict, dynamic introduction of [cont] within [_doc] is not allowed"
      }
    ],
    "type" : "strict_dynamic_mapping_exception",
    "reason" : "mapping set to strict, dynamic introduction of [cont] within [_doc] is not allowed"
  },
  "status" : 400
}

3、Flattened  类型产生的背景

如前分析,将 dynamic 设置为 false 或者 strict 不是普适的解决方案 ,如日志场景需求如下:

  • 一方面:期望能动态添加字段。strict 过于严谨会导致新字段数据拒绝写入,dynamic 过于松散会字段膨胀。

  • 另一方面:不期望索引字段膨胀。

这就导致同时满足上述两个方面的 Flattend 字段的诞生。

Flattened  中文释义:“压扁、弄平”,实际就是字段扁平化的意思。

当面临处理包含大量不可预测字段的文档时,使用 Flattend 类型可以通过将整个 JSON 对象及其嵌套 Nested 字段索引为单个关键字 keyword 类型字段来帮助减少字段总数。

Flattened 类型的最早发布在:7.3 版本

4、Flattened 类型解决的根本问题

特定日志场景、电商场景,Elasticsearch Mapping 字段数有时是无法预知的。如果随着新写入数据激增,字段也激增,可能带来的后果是什么呢?

Elasticsearch 必须为每个新字段更新集群状态,并且必须将此集群状态传递给所有节点。由于跨节点的集群状态传输是单线程操作,因此需要更新的字段映射越多,完成更新所需的时间就越长。这种延迟通常大大降低集群性能,有时会导致整个集群宕机。这被称为“ Mapping 爆炸”(mapping explosion)。

这也是 Elasticsearch 从 5.x 及更高版本将索引中的字段数限制为 1000 的原因之一。如果实战业务场景字段数超过 1000,我们必须手动更改默认索引字段限制或者重新考虑架构重构。

修改默认值的方式如下:

PUT record_infos
{
  "settings": {
    "index.mapping.total_fields.limit": 2000
  }
}

Flattened  扁平化字段就是解决:“Mapping 爆炸”问题的。

5、Flattened  类型实战解读

5.1 Flattened  类型真容

千呼万唤始出来,Flattend 真容如下:

这和 Integer、long、nested、join 等都属于字段类型的范畴。

Flattened  本质是:将原来一个复杂的 Object 或者 Nested 嵌套多字段类型统一映射为偏平的单字段类型。

这里要强调的,不管原来内嵌多少个字段,内嵌多少层,有了 Flattend,一下都打平!!

5.2 基于 Flattened 类型插入数据

基于上面的 Mapping,写入一条数据如下:

PUT demo-flattened/_doc/1
{
  "message": "[5592:1:0309/123054.737712:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.",
  "fileset": {
    "name": "syslog"
  },
  "process": {
    "name": "org.gnome.Shell.desktop",
    "pid": 3383
  },
  "@timestamp": "2020-03-09T18:00:54.000+05:30",
  "host": {
    "hostname": "bionic",
    "name": "bionic"
  }
}

这时候再查看 Mapping, 如下:

由于 host 字段设置为:Flattened,其下的:hostname、name 字段都不再映射为特定嵌套子字段。

5.3 更新 Flattened 字段,添加数据

POST demo-flattened/_update/1
{
  "doc": {
    "host": {
      "osVersion": "Bionic Beaver",
      "osArchitecture": "x86_64"
    }
  }
}

再次查看 Mapping,依然“岿然不动”。继续 Flattened 拉平,没有字段扩增,也就不会再有 “Mapping 爆炸”出现。

5.4 Flattened 类型检索

以下两种检索都会召回数据:

GET demo-flattened/_search
{
  "query": {
    "term": {
      "host": "Bionic Beaver"
    }
  }
}
GET demo-flattened/_search
{
  "query": {
    "term": {
      "host.osVersion": "Bionic Beaver"
    }
  }
}

而,如下的检索,则返回结果为空。

GET demo-flattened/_search
{
  "query": {
    "match": {
      "host.osVersion": "bionic beaver"
    }
  }
}

GET demo-flattened/_search
{
  "query": {
    "match": {
      "host.osVersion": "Beaver"
    }
  }
}

为什么呢?

由于使用 Flattened 扁平化类型,Elasticsearch 未对该字段进行分析,因此它只会返回匹配字母大小写且完全一致的结果。

如上检索结果和 keyword 类型检索结果一致。

这也初步暴露出:Flattened 类型的部分缺陷。

5.5 Flattend 类型的不足

每当面临 Flattened 扁平化对象的决定时,在选型 Elasticsearch 扁平化数据类型时,我们需要考虑以下几个关键限制:

Flattened 类型支持的查询类型目前仅限于以下几种:

  • term

  • terms

  • terms_set

  • prefix

  • range

  • match and multi_match

  • query_string and simple_query_string

  • exists

Flattened 不支持的查询类型如下:

  • 无法执行涉及数字计算的查询,例如:range query。

  • 无法支持高亮查询。

  • 尽管支持诸如 term 聚合之类的聚合,但不支持处理诸如“histograms”或“date_histograms”之类的数值数据的聚合。

6、小结

Flattened 类型的出现,解决了字段膨胀引起的 Mapping 爆炸问题,如果您的生产环境高于7.3版本,有文章开头类似问题,可以小心求证、大胆尝试这种新类型。

您生产环境使用 Flattened 类型了吗?您有没有遇到过字段膨胀或“Mapping 爆炸”问题,是如何解决的?

欢迎留言说一下您的实战思考!

ps:文章标题灵感起源于球友微信交流,对球友表示感谢!

参考

https://coralogix.com/blog/flattened-datatype-mappings-elasticsearch-tutorial/

https://www.elastic.co/guide/en/elasticsearch/reference/master/flattened.html#flattened

推荐

1、Elasticsearch 7.X 进阶实战私训课

2、如何系统的学习 Elasticsearch ?

3、全网首发!《 Elasticsearch 最少必要知识教程 V1.0 》低调发布

4、从实战中来,到实战中去——Elasticsearch 技能更快提升方法论

5、刻意练习 Elasticsearch 10000 个小时,鬼知道经历了什么?!

6、干货 | Elasticsearch Nested类型深入详解

更短时间更快习得更多干货!

中国50%+Elastic认证工程师出自于此!

比同事抢先一步学习进阶干货!

以上是关于Elasticsearch 字段膨胀不要怕,Flattened 类型解千愁!的主要内容,如果未能解决你的问题,请参考以下文章

年轻,不要怕来不及

Elasticsearch基础之_source字段

扒一扒PROMISE的原理,大家不要怕!

怕什么来不及

我们遇到什么困难都不要怕,微笑着面对它

如何在解析字段之前膨胀 GraphQL 项目?