ElasticSearch 是一个高可用开源全文检索和分析组件。提供存储服务，搜索服务，大数据准实时分析等。一般用于提供一些提供复杂搜索的应用。
ElasticSearch 提供了一套基于restful风格的全文检索服务组件。前身是compass，直到2010被一家公司接管进行维护，开始商业化，并提供了ElasticSearch 一些相关的产品，包括大家比较熟悉的 kibana、logstash 以及 ElasticSearch 的一些组件，比如 安全组件shield 。当前最新的ElasticSearch 版本为 5.1.1 ，比较应用广泛的为 2.X，直到 2016年12月推出了5.x 版本，将版本号调为 5.X 。这是为了和 kibana 和 logstash 等产品版本号进行统一 ElasticSearch 。我们将从以下几个问题快速了解一些ElasticSearch索引服务器。推荐了解Java中级程序员学习线路图。
一、ES是如何产生背景
1、大规模数据如何检索? 当系统数据量上了10亿、100亿条的时候，我们在做系统架构的时候通常会从以下角度去考虑问题：
1)用什么数据库好?(mysql、sybase、oracle、达梦、神通、mongodb、hbase…)
2)如何解决单点故障; (lvs、F5、A10、Zookeep、MQ)
3)如何保证数据安全性;(热备、冷备、异地多活)
4)如何解决检索难题;(数据库代理中间件：mysql-proxy、Cobar、MaxScale等;)
5)如何解决统计分析问题;(离线、近实时)
2、传统数据库的应对解决方案 对于关系型数据，我们通常采用以下或类似架构去解决查询瓶颈和写入瓶颈：
1)通过主从备份解决数据安全性问题;
2)通过数据库代理中间件心跳监测，解决单点故障问题;
3)通过代理中间件将查询语句分发到各个slave节点进行查询，并汇总结果
3、非关系型数据库的解决方案
对于Nosql数据库，基本原理类似：
1)通过副本备份保证数据安全性;
2)通过节点竞选机制解决单点问题;
3)先从配置库检索分片信息，然后将请求分发到各个节点，最后由路由节点合并汇总结果
4、另辟蹊径完全把数据放入内存怎么样? 我们知道，完全把数据放在内存中是不可靠的，实际上也不太现实，当我们的数据达到PB级别时，按照每个节点 96G内存计算，在内存完全装满的数据情况下，我们需要的机器是：1PB=1024T=1048576G 节点数 =1048576/96=10922个 实际上，考虑到数据备份，节点数往往在2.5万台左右。成本巨大决定了其不现实!
从前面讨论我们了解到，把数据放在内存也好，不放在内存也好，都不能完完全全解决问题。 全部放在内存速度问题是解决了，但成本问题上来了。 为解决以上问题，从源头着手分析，通常会从以下方式来寻找方法：
1、存储数据时按有序存储;
2、将数据和索引分离;
3、压缩数据; 这就引出了Elasticsearch
二、ES基础知识
1、ES主要解决问题
1)检