Elasticsearch简介

什么是elasticsearch?

Elasticsearch是一个基于Apache Lucene(TM)的开源搜索引擎。无论在开源还是专有领域，Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。

但是，Lucene只是一个库。想要使用它，你必须使用Java来作为开发语言并将其直接集成到你的应用中，更糟糕的是，Lucene非常复杂，你需要深入了解检索的相关知识来理解它是如何工作的。

Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。

不过，Elasticsearch不仅仅是Lucene和全文搜索，我们还能这样去描述它：

分布式的实时文件存储，每个字段都被索引并可被搜索

分布式的实时分析搜索引擎

可以扩展到上百台服务器，处理PB级结构化或非结构化数据

而且，所有的这些功能被集成到一个服务里面，你的应用可以通过简单的RESTful API、各种语言的客户端甚至命令行与之交互。

上手Elasticsearch非常容易。它提供了许多合理的缺省值，并对初学者隐藏了复杂的搜索引擎理论。它开箱即用（安装即可使用），只需很少的学习既可在生产环境中使用。

Elasticsearch在Apache 2 license下许可使用，可以免费下载、使用和修改。

随着你对Elasticsearch的理解加深，你可以根据不同的问题领域定制Elasticsearch的高级特性，这一切都是可配置的，并且配置非常灵活。

elasticsearch与solr对比

1)http://i.zhcy.tk/blog/elasticsearchyu-solr/

2)http://solr-vs-elasticsearch.com/

总的来说：elasticsearch在实时搜索、分布式管理上优于solr。

elasticsearch术语

1）NRT(Near Realtime)

在增删改后，有refresh interval秒（通常是1s）的延迟才能反映到数索引里。

2)  集群

多个节点逻辑上表现为一个结点，统一对外提供index和search服务；一个ES实例可以包含多个集群，每一个集群通过cluster name来标识。

3）Node

指定节点名称，不指定的话是随机的；节点具有index和search能力。

4）index索引

文档集合；一个集群可以有多个索引。

5）type

一个索引可以有多个type，一个type里面包含一类文档。类比数据就是表table。

6）文档

json形式的数据结构，类比数据库就是表中的一条记录。

7）shard & replicas 主分片和副本

一个索引中的数据，会被分成多个shard，存储在1个或多个节点里。每个shard其实就是一个功能独立的索引，放在哪个节点都可以工作。（可以增加水平扩展能力，和并行处理能力）

副本是主分片的副本，主分片不可用时候的备份。每个主分片可以有多个副本。高可用的保障。

2 集群安装

1) 压缩包解压 直接elasticsearch -d后台执行

Note：

官方推荐的系统配置：

1 文件描述符推荐32k和64k

2 vm.max_map_counts=262144

3 锁住内存，禁止swap

3 深入原理

3.1 es是如何启动的?

1）每个es实例启动的时候，都会使用自动发现机制，发现其他节点

2）自动发现机制有多播和单播两种

3）不同网段间的多播会失效

4）可以直接禁止多播，只使用单播

5) 启动的过程中会选举master节点，master选举后，一个集群才成立。

Note：

选举master节点的，最小master数量节点设置

discovery.zen.minimum_master_nodes = number of master / 2 + 1；

防止脑裂：脑裂就是一个集群被分为多个集群，有多个master同时存在。

3.2 es是如何索引的？

1）首先创建索引

2）然后创建type和mapping

3）将索引的doc，写到主分片。

5）主分片会同步到副本后，返回索引请求。

3.3 es是如何查询的？

1）搜索相比索引会更复杂，因为在搜索中哪些doc会被命中以及它们的分片分布是未知的

2）查询分两个阶段，第一个阶段是查询阶段（query）

3）查询阶段里，搜索请求会广播给所有分片（主分片或副本），每个分片会在本地执行该搜索，匹配的文档被保存到一个优先队列中，队列大小=offset + limit。

4）每个分片都准备好了队列后，将ids和需要排序的字段，如_score返回给协调节点。

5）协调节点会将所有doc排序后放入优先级队列，然后执行获取数据阶段（fetch）

6）协调节点执行fetch阶段的时候，是经过优化考虑的，会进行multiget批量获取数据。

7）所有数据获取之后，response。

3.4 es数据是如何写到磁盘的

1）数据要想searchable，必须是存在段文件(segment)的，segment就是倒排索引。

2)  数据来源是内存buffer，新的索引数据首先到内存中，然后经过refresh_interval的时间会建立segment文件写到文件系统缓存中，此时可以提供搜索。

3）索引数据在写入内存buffer的同时，还会记录事务日志，保证数据可靠。

4）经过默认30分钟，或事务日志大小超过一定范围，会强制将文件系统缓存flush到disk中，这样segment文件就写入磁盘了，事物日志也会清除，commit文件也会随之更新（commit文件记录了segment的信息）。

3.5 每个refresh-intalval间隔都会产生segment文件，文件太多怎么办？

1）文件过多会导致文件句柄，内存，cpu的消耗，因为每个segment文件都要参与计算的。

2）es对此有segment文件合并机制。是额外线程后台负责执行的，segment文件merge的时候，也是逻辑删除的doc被物理删除的时机。

3）大小相似的segment会被选中进行merge，merge成较大的segment，merge完成之后，新生成的大segment提供search，旧的小segment被物理delete

4) 可视化直观感受下lucene的合并：http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html

3.6 控制doc落在哪个shard？

1）依赖的是elasticsearch的路由机制(_reroute)

2）默认路由使用_id, (_id % number of shard)

3) 在索引的时候可以自定义路由，比如bizacctid，那么同一商家的项目会落在同一shard。（好处是搜索请求不用广播，就可以直接去指定shard搜索，弊端是有可能造成shard的大小不均）。

3.7 es使用的缓存？

1）过滤器缓存,filter cache,默认占用10%heap，LRU换出策略。Node级别，记录那些doc符合此filter，使用数据结构是bitset，空间占用少。

2）field cache缓存。

需要访问字段值的时候，例如根据某个字段排序，需要知道doc的field的value是什么，倒排索引不能完成这个，所以类似将倒排倒转过来，存储在heap缓存中，只进不出。容易OOM

只进不出是因为建立field data是一个耗时的动作。