概述
近期一直在负责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。
