Elasticsearch实战总结

上手elasticsearch有段时间了，主要以应用为主，未做深入的研究，下面就简单的日常作个简单的总结，做个记录。

版本问题

es版本繁杂，让首次使用的人无从下手。常见的有2+、5+版本，最新版已达6.1，迭代速度还是比较快的，但有个问题值得注意：每个版本间的API并不是完全兼容。

版本迭代速度快，导致的另一个问题外围的工具有些跟不上，比如客户端、迁移工具等等。建议采用5+版本。不至于太旧，享受不了新版本的功能，也不至于太新，导致外围工具用不了。

数据迁移

版本迭代速度快，你在用的版本会很快显得有些老旧，为享受到最新版本带来的益处，数据迁移是个必然的过程。

除了自己编码迁移外，还有几款方式可以使用，如Elasticsearch-dump、Elasticsearch-Exporter、logstash、snapshot、物理拷贝等。

各工具的使用依然受制于es的版本，如果采用snapshot备份、恢复，数据量大小不受限制，但不能跨版本使用，比如2+版本数据可以直接迁移至5+，但2+不能直接迁移至6+，只能通过5+版本做个过渡。

若不同版本间迁移数据，不建议采用物理拷贝的方式，以免出现意想不到的问题。如果使用dump的工具，数据量大的时候就显得不妥。数据集大的情况下，采用snapshot方式是较好的选择。

API

es基于lucene，sorl亦是基于lucene，所以这三者在使用方式上基本类似，有lucene或sorl基础的话，es的学习成本几乎更低。但每个版本的API又不完全一样，手机号码买号无缝迁移几乎不可能。还好es的提供RESTFul形式的http接口，语言无关性使其可以应用于各种语言体系下。

具体到Java体系下，就是Node client,Transport client,Rest client,Spring-data-elasticsearch,Spring-data-jest等等，可选择范围还是比较广泛的，鉴于es的版本迭代速度较快，API编写也要考虑es的版本问题。

安全问题

es本身安全方面做的不足，后来elastic公司出品了x-pack组件，来强化中间件的安全性。可惜的是，免费版本在安全方面基本缺失，但可以借助反向代理工具如Nginx或端口限制来提高其访问控制权限。

实际应用

结合Beats的ELK Stack或者是EFK（fluent）应用是比较常见的日志分析、监控架构，es被编写的初衷是为了让自己老婆方便搜索菜谱，当然这个愿望目前也没实现。

es更多的是在搜索引擎领域的应用，比如常见的搜索功能：近义词搜索、自动纠错、搜索结果分类聚合、拼音搜索、首拼搜索、检索关键字高亮等等。

电商应用中常用的推荐功能，采用es+mahout的方式也可以实现，收集用户的行为数据后，依托一定的基础算法就可以实现常见的：买过的还买了、看过的又看了、猜你喜欢等电商网站常见的功能，来促进销售。

虽说es为搜索而存在，在某些场景下，也需要实现数据的精确匹配搜索，在大数据量的情况下，比如千万级、亿级，在无特殊优化的情况下，其搜索效率远非Mysql等关系性库可比拟的，所以一般一些增量比较大、变化频率不高的数据，存储在es中是个极佳的选择。

大数据应用当下是如日中天，结合es-hadoop插件，es可以方便的与hadoop体系数据关联起来。

相关工具

成熟的产品总离不开外围丰富的工具集，es也不例外，比如官方的ELK Stack套件、X-pack、Beats工具集、APM应用等，es与mysql等关系数据库数据互通的工具elasticsearch-jdbc，监控es集群的Kopf插件，简单的UI访问管理工具-head插件，实现中文分词的ik的插件等等，还有其它插件工具集，网络搜索“Elasticsearch扩展性插件”就可以看到N多丰富的工具可用。

数据扩展

天生设计为分布式存储的es，集群配置更是简单的无以复加，只要把cluster.name设置相同，部署在同一可以发现的网段内，端口不冲突即可完成简单集群的配置，不熟悉数据分片采用默认配置即可，需要的话就特殊关注下分片策略的问题，生产环境最简单的应用建议部署两个实例，实现数据的简单备份。

关于上面提到es的常见搜索、推荐功能，后面会针对做一系列实践，逐个实现，降低入门者上手的门槛。