ElasticSearch:一个基于Lucene的搜索服务器
- 一个分布式,高性能、高可用、可伸缩的搜索和分析系统
- 提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口
- 是用Java开发,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎
- 设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便
应用场景
- 维基百科
- The Guardian(国外新闻网站)
- Stack Overflow(国外的程序异常讨论论坛)
- GitHub
- 电商网站
- 日志数据分析
- 商品价格监控网站
- BI系统
- 站内搜索
架构
- Gateway: ElasticSearch用来存储索引的文件系统,支持多种类型
- Discovery: ElasticSearch的节点发现模块,不同机器上的ES节点要组成集群需要进行消息通信,集群内部需要选举master节点,这些工作都是由Discovery模块完成。支持多种发现机制,如Zen、EC2、gce、Azure。Scripting用来支持在查询语句中插入javascript、python等脚本语言,scripting模块负责解析这些脚本,使用脚本语句性能稍低。ES也支持多种第三方插件
- JMX: java的管理框架,用来管理ES应用
Gateway的上层是一个分布式的lucene框架。Lucene之上是ElasticSearch的模块,包括:索引模块、搜索模块、映射解析模块等
ElasticSearch模块之上是 Discovery、Scripting和第三方插件
再上层是ElasticSearch的传输模块和JMX.传输模块支持多种传输协议,如Thrift、memecached、http,默认使用http
最上层是ES提供给用户的接口,可以通过RESTful接口和ES集群进行交互索引底层机制
分词索引机制
数据存储,数据可靠性
- 节点(Node):物理概念,一个运行的Elasticearch实例,一般是一台机器上的一个进程
- 索引(Index),逻辑概念,包括配置信息mapping和倒排正排数据文件,一个索引的数据文件可能会分布于一台机器,也有可能分布于多台机器。索引的另外一层意思是倒排索引文件
- 分片(Shard):为了支持更大量的数据,索引一般会按某个维度分成多个部分,每个部分就是一个分片,分片被节点(Node)管理。一个节点(Node)一般会管理多个分片,这些分片可能是属于同一份索引,也有可能属于不同索引,但是为了可靠性和可用性,同一个索引的分片尽量会分布在不同节点(Node)上。分片有两种,主分片和副本分片
- 副本(Replica):同一个分片(Shard)的备份数据,一个分片可能会有0个或多个副本,这些副本中的数据保证强一致或最终一致
- Index 1:蓝色部分,有3个shard,分别是P1,P2,P3,位于3个不同的Node中,这里没有Replica
- Index 2:绿色部分,有2个shard,分别是P1,P2,位于2个不同的Node中。并且每个shard有一个replica,分别是R1和R2。基于系统可用性的考虑,同一个shard的primary和replica不能位于同一个Node中。这里Shard1的P1和R1分别位于Node3和Node2中,如果某一刻Node2发生宕机,服务基本不会受影响,因为还有一个P1和R2都还是可用的。因为是主备架构,当主分片发生故障时,需要切换,这时候需要选举一个副本作为新主,这里除了会耗费一点点时间外,也会有丢失数据的风险
Index流程
建索引(Index)时,一个Doc先是经过路由规则定位到主Shard,发送这个doc到主Shard上建索引,成功后再发送这个Doc到这个Shard的副本上建索引,等副本上建索引成功后才返回成功。
在这种架构中,索引数据全部位于Shard中,主Shard和副本Shard各存储一份。当某个副本Shard或者主Shard丢失(比如机器宕机,网络中断等)时,需要将丢失的Shard在其他Node中恢复回来,这时候就需要从其他副本(Replica)全量拷贝这个Shard的所有数据到新Node上构造新Shard。这个拷贝过程需要一段时间,这段时间内只能由剩余主副本来承载流量,在恢复完成之前,整个系统会处于一个比较危险的状态,直到failover结束。
这里就体现了副本(Replica)存在的一个理由,避免数据丢失,提高数据可靠性。副本(Replica)存在的另一个理由是读请求量很大的时候,一个Node无法承载所有流量,这个时候就需要一个副本来分流查询压力,目的就是扩展查询能力。