ElasticSearch不停机重建索引引申来的优化与思考

前言

距离我第一次上手ES过去了一年半多了吧，当时我是从零开始花了大半年时间搭建了一整套Filebeat+Kafka+数据处理服务+Elasticsearch+Kibana+Skywalking日志收集系统。感觉还是很刺激的，毕竟同时去深度学习和运用多个刚上手的中间件对我来说是个极大的磨练。日志收集系统的数据处理服务切换到了Flink，这个后面总结完毕后我会出一篇单独的文章讲讲Flink和改造过程。但是始终有一个问题困扰着我，团队内部对于ES的应用尚浅，仅仅用来做日志收集，导致我对ES的认识一直不算深刻，所以我之前也没有写一篇优秀的文章来阐述我的认知。当然现在我依旧算个小白，但是因为一两个需求重新深刻认识了ES，算是一段不错的经历，因此分享给大家，有问题的话请各位大佬指正。

需求

同事提给我的，说是需要对过去半年时间做一个系统应用的用户使用情况统计，很急。具体是需要按照系统分组统计每个用户的使用情况，很好，之前完全没有单独设计过相关的统计入口，因此只能根据日志内容硬写查询语句了。因为需求比较麻烦，所以注定是个复杂聚合查询，不巧的是我对于ES的查询API有点忘了，只能现学现卖了。为啥不熟呢？我自己总结的原因一是日志场景单一，JavaAPI只需要布尔查询拼条件即可，不会很复杂，后面改成Kibana后索引模式用上就不存在什么API调用了。原因二是由于工作繁忙，没有别的技术场景，因此没有太关注ES的API部分，重点都是在性能优化和日志收集系统的完善上面。

除了上面的复杂查询让我稍微感到难度之外，在聚合查询的时候还发现了历史遗留的问题，新索引优化了映射并没有修改老索引，因此新老索引映射是有一点区别的，需要重建索引。重建索引自然要上真实场景ÿ