logo头像

待到风起时,扬帆济沧海

elasticsearch核心概念(初版)

本文于308天之前发表,文中内容可能已经过时。

核心概念

Node 与 Cluster

Elastic 本质上是一个分布式数据库,允许多台服务器协同工作,每台服务器可以运行多个 Elastic 实例。

单个 Elastic 实例称为一个节点(node)。一组节点构成一个集群(cluster)。

Index

Elastic 会索引所有字段,经过处理后写入一个反向索引(Inverted Index)。查找数据的时候,直接查找该索引。

所以,Elastic 数据管理的顶层单位就叫做 Index(索引)。它是单个数据库的同义词。每个 Index (即数据库)的名字必须是小写。

下面的命令可以查看当前节点的所有 Index。

1
$ curl -X GET 'http://localhost:9200/_cat/indices?v'

Document

Index 里面单条的记录称为 Document(文档)。许多条 Document 构成了一个 Index。

Document 使用 JSON 格式表示,下面是一个例子。

1
2
3
4
5
{
"user": "张三",
"title": "工程师",
"desc": "数据库管理"
}

同一个 Index 里面的 Document,不要求有相同的结构(scheme),但是最好保持相同,这样有利于提高搜索效率。

Type

Document 可以分组,比如weather这个 Index 里面,可以按城市分组(北京和上海),也可以按气候分组(晴天和雨天)。这种分组就叫做 Type,它是虚拟的逻辑分组,用来过滤 Document。

不同的 Type 应该有相似的结构(schema),举例来说,id字段不能在这个组是字符串,在另一个组是数值。这是与关系型数据库的表的一个区别。性质完全不同的数据(比如productslogs)应该存成两个 Index,而不是一个 Index 里面的两个 Type(虽然可以做到)。

下面的命令可以列出每个 Index 所包含的 Type。

1
$ curl 'localhost:9200/_mapping?pretty=true'

es与数据库类比

es 数据库
document
type
index 数据库

share(primary 数据分片) & replica(replica share数据副本) 深入理解

1)一个index包含多个share
2)每个share都是一个最小工作单元,包含完整的lucene实例,完整的建立索引和处理业务能力
3)增加节点时,share会自动在node中负载
4)每个document只存在一个share和其对应的replica中,不可能存在多个share中
5)replica数据副本,负责容错和负载
6)primary share在创建index的时候就已经确定了,replica share可以随时更改
7)primary share默认是5个,每个primary share有1个replica share,所以一个节点默认5个primary share和5个replica share
8)primary share和自己的replica share不能放在同一个节点上,避免宕机,但是可以同其他rimary share的replica share在同一个节点

document删除(或者全量替换)

  • 删除的时候只是打了标记,并没有实时删除,es后台会在到达一定量的时候物理删除
  • 全量替换也是打了标记,所以数据的version会变

version并发版本控制和乐观锁

什么是partial update && 实现原理

POST /index/type/id/_update

1
2
3
4
5
{
"doc": {
"要修改的几个少数filed,不需要全量的数据"
}
}

内部原理:其实es跟传统全量替换一样,只不过是ES内部share完成

  1. 获取到document
  2. 将传过来的filed更新到document的json中,存放在内存中
  3. 将老的document标记为删除
  4. 将新的document创建出来
    优点:
  5. 由于是内部完成,减少网络请求开销,一瞬间完成
  6. 减少并发造成的问题

bulk语法


调优

仅索引层面调优手段:

  • 1.1、设计阶段调优
    1)根据业务增量需求,采取基于日期模板创建索引,通过roll over API滚动索引;
    2)使用别名进行索引管理;
    3)每天凌晨定时对索引做force_merge操作,以释放空间;
    4)采取冷热分离机制,热数据存储到SSD,提高检索效率;冷数据定期进行shrink操作,以缩减存储;
    5)采取curator进行索引的生命周期管理;
    6)仅针对需要分词的字段,合理的设置分词器;
    7)Mapping阶段充分结合各个字段的属性,是否需要检索、是否需要存储等。
  • 1.2、写入调优
    1)写入前副本数设置为0;
    2)写入前关闭refresh_interval设置为-1,禁用刷新机制;
    3)写入过程中:采取bulk批量写入;
    4)写入后恢复副本数和刷新间隔;
    5)尽量使用自动生成的id。
  • 1.3、查询调优
    1)禁用wildcard;
    2)禁用批量terms(成百上千的场景);
    3)充分利用倒排索引机制,能keyword类型尽量keyword;
    4)数据量大时候,可以先基于时间敲定索引再检索;
    5)设置合理的路由机制。

ES中的倒排索引是什么?

传统的检索方式是通过文章,逐个遍历找到对应关键词的位置。
倒排索引,是通过分词策略,形成了词和文章的映射关系表,也称倒排表,这种词典 + 映射表即为倒排索引。

其中词典中存储词元,倒排表中存储该词元在哪些文中出现的位置。
有了倒排索引,就能实现 O(1) 时间复杂度的效率检索文章了,极大的提高了检索效率。
倒排索引的底层实现是基于:FST(Finite State Transducer)数据结构。

Lucene 从 4+ 版本后开始大量使用的数据结构是 FST。FST 有两个优点:
1)空间占用小。通过对词典中单词前缀和后缀的重复利用,压缩了存储空间;
2)查询速度快。O(len(str)) 的查询时间复杂度。

ES是如何实现master选举的?

  • 前置条件:
    1)只有是候选主节点(master:true)的节点才能成为主节点。
    2)最小主节点数(min_master_nodes)的目的是防止脑裂。
  • 选举流程大致描述如下:
    第一步:确认候选主节点数达标,elasticsearch.yml 设置的值 discovery.zen.minimum_master_nodes;
    第二步:对所有候选主节点根据nodeId字典排序,每次选举每个节点都把自己所知道节点排一次序,然后选出第一个(第0位)节点,暂且认为它是master节点。
    第三步:如果对某个节点的投票数达到一定的值(候选主节点数n/2+1)并且该节点自己也选举自己,那这个节点就是master。否则重新选举一直到满足上述条件。

如何解决ES集群的脑裂问题

所谓集群脑裂,是指 Elasticsearch 集群中的节点(比如共 20 个),其中的 10 个选了一个 master,另外 10 个选了另一个 master 的情况。

当集群 master 候选数量不小于 3 个时,可以通过设置最少投票通过数量(discovery.zen.minimum_master_nodes)超过所有候选节点一半以上来解决脑裂问题;
当候选数量为两个时,只能修改为唯一的一个 master 候选,其他作为 data 节点,避免脑裂问题。

详细描述一下ES索引文档的过程?

1.png

第一步:客户端向集群某节点写入数据,发送请求。(如果没有指定路由/协调节点,请求的节点扮演协调节点的角色。)
第二步:协调节点接受到请求后,默认使用文档 ID 参与计算(也支持通过 routing),得到该文档属于哪个分片。随后请求会被转到另外的节点。路由算法:根据文档id或路由计算目标的分片id shard = hash(document_id) % (num_of_primary_shards)
第三步:当分片所在的节点接收到来自协调节点的请求后,会将请求写入到 Memory Buffer,然后定时(默认是每隔 1 秒)写入到F ilesystem Cache,这个从 Momery Buffer 到 Filesystem Cache 的过程就叫做 refresh;
第四步:当然在某些情况下,存在 Memery Buffer 和 Filesystem Cache 的数据可能会丢失,ES 是通过 translog 的机制来保证数据的可靠性的。其实现机制是接收到请求后,同时也会写入到 translog 中,当 Filesystem cache 中的数据写入到磁盘中时,才会清除掉,这个过程叫做 flush;
第五步:在 flush 过程中,内存中的缓冲将被清除,内容被写入一个新段,段的 fsync 将创建一个新的提交点,并将内容刷新到磁盘,旧的 translog 将被删除并开始一个新的 translog。
第六步:flush 触发的时机是定时触发(默认 30 分钟)或者 translog 变得太大(默认为 512 M)时。

在并发情况下,ES如果保证读写一致?

可以通过版本号使用乐观并发控制,以确保新版本不会被旧版本覆盖,由应用层来处理具体的冲突;
另外对于写操作,一致性级别支持quorum/one/all,默认为quorum,即只有当大多数分片可用时才允许写操作。但即使大多数可用,也可能存在因为网络等原因导致写入副本失败,这样该副本被认为故障,分片将会在一个不同的节点上重建。
对于读操作,可以设置replication为sync(默认),这使得操作在主分片和副本分片都完成后才会返回;如果设置replication为async时,也可以通过设置搜索请求参数_preference为primary来查询主分片,确保文档是最新版本。

lucence内部结构

1.jpeg

评论系统未开启,无法评论!