概述
es
存储中大体可以看成index(表) + document(行记录)
组成
es
支持分布式存储,一个index
会产生多个分片,保存在不同的实例上。其中分为若干个主分片
和副分片
。当主分片挂了,会切换到副分片,主分片和副分片的数据是一致的(写的时候先找主分片,读的时候是2者都可以)。这个切换的过程由es
集群节点中的leader
决定。如果当前的leader
挂了,会选举出一个新leader
。
es读和写的过程(近实时查询原因)
写:客户端会选择一个node
节点**(协调节点)**请求过去,然后节点会对这个document
数据进行路由,转发给对应的主分片所在node
上。实际处理的node
处理完之后会同步到副分片所在节点。主分片和副分片都完成之后,响应客户端处理成功。
这里的写只是写到了FileSystem Cache
;即es
和磁盘中间的一层缓存。将数据刷到磁盘需要一个fsync
操作,这个操作是比较耗时的,要是每条数据写入都同步触发,那性能太差了。
所以在es
中新增的document
会被收集到indexing buffer
区后被重写成一个segment
然后直接写入filesystem cache
中,这个操作是非常轻量级的,相对耗时较少,之后经过一定的间隔或外部触发后才会被flush
到磁盘上,这个操作非常耗时。但只要sengment
文件被写入cache
后,这个sengment
就可以打开和查询,从而确保在短时间内就可以搜到,而不用执行一个full commit
也就是fsync
操作,这是一个非常轻量级的处理方式而且是可以高频次的被执行,而不会破坏es
的性能
在elasticsearch
里面,这个轻量级的写入和打开一个cache
中的segment
的操作叫做refresh
,默认情况下,es
集群中的每个shard
会每隔1秒
自动refresh
一次,这就是我们为什么说es
是近实时的搜索引擎而不是实时的,也就是说给索引插入一条数据后
,我们需要等待1秒
才能被搜到这条数据,这是es
对写入和查询一个平衡的设置方式,这样设置既提升了es
的索引写入效率同时也使得es
能够近实时检索数据。
读(根据id读):读取数据也是先选一个node
节点**(协调节点)**发请求过去,节点会把id
进行hash
,转发到实际的node
中,然后在主分片和副分片中随机轮询进行查询。
搜索原理
搜索:es
的搜索主要依靠的就是倒排索引,开始也是客户端选择一个node
节点**(协调节点)**请求过去,然后转发到所有的shard
分片对应的主/副分片,每个分片将搜索对应的document
id
和score
等信息返回给一开始的协调节点,然后协调节点排序完
之后根据id
拿到对应的document
数据再返回给客户端。文章来源:https://www.toymoban.com/news/detail-702188.html
深度分页问题
分页:es
的分页在深度分页下性能会很差,比如查询10000
页的1000
条数据,es
的协调节点会从所有分片中拉取10000
条到协调节点,即总数据=分片数量X10000
.然后在协调节点里处理得到最后的1000
条数据。文章来源地址https://www.toymoban.com/news/detail-702188.html
到了这里,关于es的数据存储结构;近实时查询原因的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!