Elasticsearch 字段膨胀不要怕,Flattened 类型解千愁!
球友问题:我记得您写过一篇关于建模字段膨胀的问题,对于比如request header response这种动态的对象,是怎么处理来着?
进一步反馈:决定升级es高版本了,Flattened 解千愁!主要我们这需求要把接口所有信息都保留,只能这样了。
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 后,再动态插入数据,会报错如下:
如前分析,将 dynamic 设置为 false 或者 strict 不是普适的解决方案 ,如日志场景需求如下:
• 一方面:期望能动态添加字段。strict 过于严谨会导致新字段数据拒绝写入,dynamic 过于松散会字段膨胀。
• 另一方面:不期望索引字段膨胀。
这就导致同时满足上述两个方面的 Flattend 字段的诞生。
Flattened 中文释义:“压扁、弄平”,实际就是字段扁平化的意思。
当面临处理包含大量不可预测字段的文档时,使用 Flattend 类型可以通过将整个 JSON 对象及其嵌套 Nested 字段索引为单个关键字 keyword 类型字段来帮助减少字段总数。
Flattened 类型的最早发布在:7.3 版本。
特定日志场景、电商场景,Elasticsearch Mapping 字段数有时是无法预知的。如果随着新写入数据激增,字段也激增,可能带来的后果是什么呢?
Elasticsearch 必须为每个新字段更新集群状态,并且必须将此集群状态传递给所有节点。由于跨节点的集群状态传输是单线程操作,因此需要更新的字段映射越多,完成更新所需的时间就越长。这种延迟通常大大降低集群性能,有时会导致整个集群宕机。这被称为“ Mapping 爆炸”(mapping explosion)。
这也是 Elasticsearch 从 5.x 及更高版本将索引中的字段数限制为 1000 的原因之一。如果实战业务场景字段数超过 1000,我们必须手动更改默认索引字段限制或者重新考虑架构重构。
修改默认值的方式如下:
5.1 Flattened 类型真容
千呼万唤始出来,Flattend 真容如下:
这和 Integer、long、nested、join 等都属于字段类型的范畴。
Flattened 本质是:将原来一个复杂的 Object 或者 Nested 嵌套多字段类型统一映射为偏平的单字段类型。
这里要强调的,不管原来内嵌多少个字段,内嵌多少层,有了 Flattend,一下都打平!!
5.2 基于 Flattened 类型插入数据
基于上面的 Mapping,写入一条数据如下:
这时候再查看 Mapping, 如下:
由于 host 字段设置为:Flattened,其下的:hostname、name 字段都不再映射为特定嵌套子字段。
5.3 更新 Flattened 字段,添加数据
再次查看 Mapping,依然“岿然不动”。继续 Flattened 拉平,没有字段扩增,也就不会再有 “Mapping 爆炸”出现。
5.4 Flattened 类型检索
以下两种检索都会召回数据:
而,如下的检索,则返回结果为空。
为什么呢?
由于使用 Flattened 扁平化类型,Elasticsearch 未对该字段进行分析,因此它只会返回匹配字母大小写且完全一致的结果。
如上检索结果和 keyword 类型检索结果一致。
这也初步暴露出:Flattened 类型的部分缺陷。
5.5 Flattend 类型的不足
每当面临 Flattened 扁平化对象的决定时,在选型 Elasticsearch 扁平化数据类型时,我们需要考虑以下几个关键限制:
Flattened 类型支持的查询类型目前仅限于以下几种:
Flattened 类型的出现,解决了字段膨胀引起的 Mapping 爆炸问题,如果您的生产环境高于7.3版本,有文章开头类似问题,可以小心求证、大胆尝试这种新类型。
您生产环境使用 Flattened 类型了吗?您有没有遇到过字段膨胀或“Mapping 爆炸”问题,是如何解决的?
欢迎留言说一下您的实战思考!
ps:文章标题灵感起源于球友微信交流,对球友表示感谢!