在深圳帮人做网站,做网站的公司都有哪些岗位,网站建设费 无形资产,全屋定制十大名牌口碑概述 近期一直在负责es这块#xff0c;就想着和大家分享一些使用经验#xff0c;我们从存储、查询、优化、备份、运维等几个方面来做分享。今天咱们先看下如何更加合理的存储数据。 初见索引模板 记得刚接触es还是18年那会#xff0c;项目上线后因一些原因导致日志这部分的…概述 近期一直在负责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。