ElasticSearch是基于Lucene的RestFul的分布式实时全文搜索引擎,每个字段都被索引并可被搜索,可以快速存储,搜索,分析海量的数据
全文搜索是针对每个词建立一个索引,指明该次在文章中出现的次数和位置,当查询的时候,根据实现建立的索引进行查找,并将查找的结果反馈给用户的检索方式
- index索引:类似于mysql中的数据库
- type类型:类似于一张表,后续已经被废弃了
- document文档:类似于mysql中的一行,不同之处在于ES中的每个文档可以由不同的字段组成,但是对于通用的字段应该有相同的数据类型,文档是es中最小的数据单元,可以认为一个文档就是一条记录
- field字段:field是es的最小单位,一个document里面有多个field
- shard分片:单台机器无法存储大量的数据,es可以将一个索引的数据切分为多个shard,分布在多台服务器上存储,有了shard就可以横向扩展,存储更多数据,提高吞吐量和性能
- replica副本:任何服务器随时可能故障或宕机,此时shard可能丢失,通过创建replica副本,可以在shard故障的时候提供备用服务,保证数据不丢失
在搜索引擎中,每个文档都有对应的文档id,文档内容被表示为一些列关键词的集合,例如,某个文档经过分词,提取了20个关键词,而通过倒排索引,可以记录每个关键词在文档中出现的次数和位置
text和keyword的区别?text会被分词,然后根据分词后的内容建立倒排索引,keyword类型不会被分词,直接根据字符串内容建立倒排索引,所以keyword类型的字段只能通过精确值搜索到
query和filter的区别?query:查询操作不仅仅会进行查询,还会计算分值,用于确定相关度
filter:查询操作仅判断是否满足查询条件,不会计算任何分值,也不会关心返回的排序问题,filter查询结果可以被缓存
ES写入数据的流程?- 客户端选择 ES 的某个 node 发送请求过去，这个 node 就是协调节点 coordinating node
- coordinating node 对 document 进行路由，将请求转发给对应的 node（primary shard）
- 实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node
- coordinating node 等到 primary node 和所有 replica node 都执行成功之后，最后返回响应结果给客户端。
主分片写入数据的详细流程:
- 数据先写入内存buffer,在写入buffer的同时会把数据写入translog日志文件
- 如果buffer快满了或者到了指定时间,es会将buffer数据refresh到一个新的segment文件中,refresh操作并非直接进入segment磁盘文件,而是先进入os cache,当buffer被刷入到os cache的时候就可以被搜索到了;
- 此后buffer的数据就会被清空,并且数据在translog日志文件里持久化到磁盘保留了一份,此时就可以让这个segment文件的数据对外提供搜索了
- 新的数据不断的进入buffer和translog,segment文件越来越多,translog文件也不断的变大,当这个过程到达一定程度的时候会执行commit操作
- commit操作首先会将buffer里的数据转移到os cache中去,清空buffer;随后将一个commit point写入磁盘文件,里面标识着这个commit point对应的所有segment文件,同时强制将os cache中的所有数据都刷新到磁盘文件中去,随后将translog文件清空,再次重启一个translog,此时commit操作完成
ES的更新和删除流程?traslog日志的作用(与mysql的redolog相似):在执行commit操作之前,数据要么停留在buffer要么停留在os cache中,一旦此时机器宕机,数据就全丢失了,因此需要将数据对应的操作写入一个专门的日志文件,也就是translog日志文件,当机器宕机重启的时候,会读取translog日志文件中的数据,恢复到buffer 和os cache中去
删除和更新都是写操作,但是由于es的文档不可变,因此不能被删除或者改动,所以es使用.del文件来标记文档是否被删除,磁盘上的每个段都有一个对应的del文件
- 如果是删除操作,文档其实并没有真的被删除,而是在del文件中标记为deleted状态,该文档依然可以参与匹配查询,只是在结果中会被过滤掉
- 如果是更新操作,就是将旧的doc标识为deleted状态,然后创建一个新的doc
ES的搜索流程?内存buffer每次refresh都会产生一个segment文件,所以默认情况下1s生成一个segment文件,所以定期会进行merge操作,每次merge的时候,将多个segment文件合成一个,同时这里会将标识为deleted的doc给删除掉,不写入到新的segment中,然后将segment文件落入磁盘,这里会写一个commit point,标识所有新的segment文件,然后打开segment文件供搜索使用,同时删除旧的segment文件
Query阶段:客户端发送请求到协调节点,协调节点广播到所有主分片和副本分片,每个分片在本地执行搜索并且构建一个匹配文档的大小为from+size的优先队列,接着每个分片返回各自的优先队列中所有docID和打分值给协调节点,由协调节点进行合并,排序,分页,产出最终结果
Fetch阶段:协调节点根据query的结果,通过对docid进行哈希路由,将请求转发给对应node,在主分片或者副本分片中随机选择一个,让读请求负载均衡,接收请求的node返回document给协调节点,最后由协调节点返回结果到客户端
ES在高并发下如何保证一致性?对于更新操作,通过乐观锁机制引入版本号机制
对于写操作:有三种一致性级别支持quorum/one/all,默认为quorum,只有当大多数分片可用时才允许写操作
对于读操作:设置replication为sync(默认),这使得操作在主分片和副本分片都完成后才会返回,如果设置为async时,也可以通过设置搜索请求参数为_preference为primary来查询主分片,确保文档是最新的版本
ES如何选举Master节点? 分布式原理?ES会对存储的数据进行切分,划分到不同的分片,每个分片会生成多个副本,这些副本位于与主分片不同的节点上,从而保证高可用,ES中节点是对等的,节点间会选出集群的master,由master会负责维护集群状态信息,并且同步给其他节点
ES如何选举Master?- 确认候选主节点的最少投票通过数量
- 选举时,集群中每个节点对所有master候选节点根据nodeID进行字典排序,然后选出第一个节点,暂且认为它是master节点
- 如果对某个节点的票数达到阈值,并且该节点自己也选取了自己,那么这个节点就是master,否则重新选举一直到满足上述条件
