1 Elasticsearch简介
1.1 什么是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的高级特性,这一切都是可配置的,并且配置非常灵活。
1.2 elasticsearch与solr对比
- http://i.zhcy.tk/blog/elasticsearchyu-solr/
- http://solr-vs-elasticsearch.com/
总的来说:elasticsearch在实时搜索、分布式管理上优于solr。
1.3 elasticsearch术语
- NRT(Near Realtime):在增删改后,有refresh interval秒(通常是1s)的延迟才能反映到数索引里。
- 集群:多个节点逻辑上表现为一个结点,统一对外提供index和search服务;一个ES实例可以包含多个集群,每一个集群通过cluster name来标识。
- Node:指定节点名称,不指定的话是随机的;节点具有index和search能力。
- index索引:文档集合;一个集群可以有多个索引。
- type:一个索引可以有多个type,一个type里面包含一类文档。类比数据就是表table。
- 文档:json形式的数据结构,类比数据库就是表中的一条记录。
- shard & replicas 主分片和副本:一个索引中的数据,会被分成多个shard,存储在1个或多个节点里。每个shard其实就是一个功能独立的索引,放在哪个节点都可以工作。(可以增加水平扩展能力,和并行处理能力)
副本是主分片的副本,主分片不可用时候的备份。每个主分片可以有多个副本。高可用的保障。
2 集群安装
- 压缩包解压 直接elasticsearch -d后台执行
Note:
官方推荐的系统配置:
- 文件描述符推荐32k和64k
- vm.max_map_counts=262144
- 锁住内存,禁止swap
3 深入原理
3.1 es是如何启动的?
- 每个es实例启动的时候,都会使用自动发现机制,发现其他节点
- 自动发现机制有多播和单播两种
- 不同网段间的多播会失效
- 可以直接禁止多播,只使用单播
- 启动的过程中会选举master节点,master选举后,一个集群才成立。
Note:
选举master节点的,最小master数量节点设置
discovery.zen.minimum_master_nodes = number of master / 2 1;
防止脑裂:脑裂就是一个集群被分为多个集群,有多个master同时存在。
3.2 es是如何索引的?
- 首先创建索引
- 然后创建type和mapping
- 将索引的doc,写到主分片。
- 主分片会同步到副本后,返回索引请求。
3.3 es是如何查询的?
- 搜索相比索引会更复杂,因为在搜索中哪些doc会被命中以及它们的分片分布是未知的
- 查询分两个阶段,第一个阶段是查询阶段(query)
- 查询阶段里,搜索请求会广播给所有分片(主分片或副本),每个分片会在本地执行该搜索,匹配的文档被保存到一个优先队列中,队列大小=offset limit。
- 每个分片都准备好了队列后,将ids和需要排序的字段,如_score返回给协调节点。
- 协调节点会将所有doc排序后放入优先级队列,然后执行获取数据阶段(fetch)
- 协调节点执行fetch阶段的时候,是经过优化考虑的,会进行multiget批量获取数据。
- 所有数据获取之后,response。
3.4 es数据是如何写到磁盘的
- 数据要想searchable,必须是存在段文件(segment)的,segment就是倒排索引。
- 数据来源是内存buffer,新的索引数据首先到内存中,然后经过refresh_interval的时间会建立segment文件写到文件系统缓存中,此时可以提供搜索。
- 索引数据在写入内存buffer的同时,还会记录事务日志,保证数据可靠。
- 经过默认30分钟,或事务日志大小超过一定范围,会强制将文件系统缓存flush到disk中,这样segment文件就写入磁盘了,事物日志也会清除,commit文件也会随之更新(commit文件记录了segment的信息)。
3.5 每个refresh-intalval间隔都会产生segment文件,文件太多怎么办?
- 文件过多会导致文件句柄,内存,cpu的消耗,因为每个segment文件都要参与计算的。
- es对此有segment文件合并机制。是额外线程后台负责执行的,segment文件merge的时候,也是逻辑删除的doc被物理删除的时机。
- 大小相似的segment会被选中进行merge,merge成较大的segment,merge完成之后,新生成的大segment提供search,旧的小segment被物理delete
- 可视化直观感受下lucene的合并:http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html
3.6 控制doc落在哪个shard?
- 依赖的是elasticsearch的路由机制(_reroute)
- 默认路由使用_id, (_id % number of shard)
- 在索引的时候可以自定义路由,比如bizacctid,那么同一商家的项目会落在同一shard。(好处是搜索请求不用广播,就可以直接去指定shard搜索,弊端是有可能造成shard的大小不均)。
3.7 es使用的缓存?
- 过滤器缓存,filter cache,默认占用10%heap,LRU换出策略。Node级别,记录那些doc符合此filter,使用数据结构是bitset,空间占用少。
- field cache缓存。
需要访问字段值的时候,例如根据某个字段排序,需要知道doc的field的value是什么,倒排索引不能完成这个,所以类似将倒排倒转过来,存储在heap缓存中,只进不出。容易OOM
只进不出是因为建立field data是一个耗时的动作。