elasticsearch列一:索引模板的使用

概述

近期一直在负责es这块,就想着和大家分享一些使用经验,我们从存储、查询、优化、备份、运维等几个方面来做分享。今天咱们先看下如何更加合理的存储数据。

初见索引模板

记得刚接触es还是18年那会,项目上线后因一些原因导致日志这部分的开发未完成,导致日志这块只能通过linux命令查询,及其不方便。

于是老大让我自己搞定这块,当时是由兄弟团队负责开发这块,所以我们的日志都只是写到了日志文件上,项目刚上线各种问题还经常需要通过日志查询,瞬间涌上心头,于是先搞个脚本把各个服务日志定时搜集到一台服务器上,避免丢失。

接下来一路趟坑便就开始了,为了快速搞起来,优先百度各种方案,提到最多的就是elk这个词,于是按照网上的方案快速搭建起来了。

但是那会只是换了方式查询,通过kibana各种维度查询,语法边百度边查询,随着时间推移日志量越来越大,慢慢的查询性能大大降低,一但出了事自己也不知道怎么运维es。

于是痛下决心开始学习官网文档,全方位了解es。首先发现存储就不对,各个字段几乎都是text格式,大大浪费了磁盘空间。于是首个模板就这么出来了。我们展示其中一段:

"properties":{                "id":{                    "type":"keyword"                },                "relativeJobId":{                    "type":"keyword"                },                "reqDate":{                    "type":  "date",                    "format": "yyyy-MM-dd HH:mm:ss"                },                "operDate":{                    "type":"date",                    "format": "yyyy-MM-dd HH:mm:ss"                },                "title":{                    "type":"text",                    "norms": false                }            }

建立好模板后再晚上业务低峰期对索引逐个进行reindex操作后发现查询能力大大提升,磁盘空间也下降很多。

索引升级

但是运行一段时间后问题出来了,我们需要扩展日志字段,并且是精确匹配,那该怎么办呢?我们可以通过动态模板的方式实现,我们看下索引模板变成了这样:

"properties":{                "id":{                    "type":"keyword"                },                "relativeJobId":{                    "type":"keyword"                },                "reqDate":{                    "type":  "date",                    "format": "yyyy-MM-dd HH:mm:ss"                },                "operDate":{                    "type":"date",                    "format": "yyyy-MM-dd HH:mm:ss"                },                "title":{                    "type":"text",                    "norms": false                }            },            "dynamic_templates": [                {                    "longs": {                        "match_mapping_type": "long",                        "mapping": {                            "type": "long"                        }                    }                },                {                    "boolean": {                        "match_mapping_type": "boolean",                        "mapping": {                            "type": "boolean"                        }                    }                },                {                    "strings_as_keywords": {                        "match_mapping_type": "string",                        "mapping": {                            "type":  "keyword"                        }                    }                },{                    "date": {                        "match_mapping_type": "date",                        "mapping": {                            "type":  "date",                            "format": "yyyy-MM-dd HH:mm:ss"                        }                    }                }            ]        }

这样一来如果新增的字段是String类型,es就会采用keyword的方式进行存储,如果是时间字段就会按照这种格式存储等等。

看似一切都解决了,但是运行一段时间后发现我们又需要增加支持模糊查询的字段,这又改怎么办呢?于是我们的索引模板就发展成了这样:​​​​​​​

"properties":{                "id":{                    "type":"keyword"                },                "relativeJobId":{                    "type":"keyword"                },                "reqDate":{                    "type":  "date",                    "format": "yyyy-MM-dd HH:mm:ss"                },                "operDate":{                    "type":"date",                    "format": "yyyy-MM-dd HH:mm:ss"                },                "title":{                    "type":"text",                    "norms": false                }            },            "dynamic_templates": [                {                    "longs": {                        "match_mapping_type": "long",                        "mapping": {                            "type": "long"                        }                    }                },                {                    "boolean": {                        "match_mapping_type": "boolean",                        "mapping": {                            "type": "boolean"                        }                    }                },                {                    "strings_as_text": {                        "match_mapping_type": "string",                        "match":   "text_*",                        "mapping": {                            "type":  "text",                            "norms": false                        }                    }                },                {                    "strings_as_keywords": {                        "match_mapping_type": "string",                        "mapping": {                            "type":  "keyword"                        }                    }                },{                    "date": {                        "match_mapping_type": "date",                        "mapping": {                            "type":  "date",                            "format": "yyyy-MM-dd HH:mm:ss"                        }                    }                }            ]        }

如果是test—开头的字段并且是String类型,es就会采用text的方式进行存储,我们可以看到有个norms的属性,我们设置了false,它是啥意思呢?我们细心点可以发现通过query查询的时候你会发现结果集中每条数据都有会有个相关度分数,这个不仅会消耗cpu还会占用一定的磁盘性能,如果我们不需要根据相关度分数进行高亮或者排序之类的,完全可以把这部分给屏蔽掉,节省磁盘空间。

其实我们还可以通过ignore_above的方式设置字段一旦超过多大后就不再支持搜索,比如你的字段是一段1mb的String字符串用它来做匹配就太过消耗性能了(单说filter查询时会通过bitset缓存,此项就会大大降低性能。),完全可以通过其附属字段进行匹配。

通过上述模板升级后,我们的模板就已经足够支持各种变化了,也就不用担心动态增加字段的问题了

总结

要想深入了解一个技术还是官方文档啊,毕竟只有官方最了解自己的产品。希望接下来一段时间我们一起跟着官方文档深入学习es。