深入理解索引原理

作者: 数据库信息  发布:2019-10-18

2.6.3实时索引

在上述的per-segment搜索的机制下,新的文档会在分钟级内被索引,但是还不够快。 瓶颈在磁盘。将新的segment提交到磁盘需要fsync来保障物理写入。但是fsync是很耗时的。它不能在每次文档更新时就被调用,否则性能会很低。 现在需要一种轻便的方式能使新的文档可以被索引,这就意味着不能使用fsync来保障。 在ES和物理磁盘之间是内核的文件系统缓存。之前的描述中,Figure19,Figure20,在内存中索引的文档会被写入到一个新的segment。但是现在我们将segment首先写入到内核的文件系统缓存,这个过程很轻量,然后再flush到磁盘,这个过程很耗时。但是一旦一个segment文件在内核的缓存中,它可以被打开被读取。

2.6.1不变性

写到磁盘的倒序索引是不变的:自从写到磁盘就再也不变。 这会有很多好处:

不需要添加锁。如果你从来不用更新索引,那么你就不用担心多个进程在同一时间改变索引。

一旦索引被内核的文件系统做了Cache,它就会待在那因为它不会改变。只要内核有足够的缓冲空间,绝大多数的读操作会直接从内存而不需要经过磁盘。这大大提升了性能。

其他的缓存(例如fiter cache)在索引的生命周期内保持有效,它们不需要每次数据修改时重构,因为数据不变。

写一个单一的大的倒序索引可以让数据压缩,减少了磁盘I/O的消耗以及缓存索引所需的RAM。

当然,索引的不变性也有缺点。如果你想让新修改过的文档可以被搜索到,你必须重新构建整个索引。这在一个index可以容纳的数据量和一个索引可以更新的频率上都是一个限制。

 

最近开始大面积使用ES,很多地方都是知其然不知其所以然,特地翻看了很多资料和大牛的文档,简单汇总一篇。内容多为摘抄,说是深入其实也是一点浅尝辄止的理解。希望大家领会精神。

首先学习要从官方开始地址如下。

es官网原文:

 

索引(Index)

   ES将数据存储于一个或多个索引中,索引是具有类似特性的文档的集合。类比传统的关系型数据库领域来说,索引相当于SQL中的一个数据库,或者一个数据存储方案(schema)。索引由其名称(必须为全小写字符)进行标识,并通过引用此名称完成文档的创建、搜索、更新及删除操作。一个ES集群中可以按需创建任意数目的索引。

如果不懂这块可以看我的写的上一篇入门的内容 http://www.cnblogs.com/wenBlog/p/8482326.html

我们了解索引的写操作后可知,更新、索引、删除文档都是写操作,这些操作必须在primary shard完全成功后才能拷贝至其对应的replicas上,默认情况下主分片等待所有备份完成索引后才返回客户端。

图片 1

步骤:

  1. 客户端向Node1 发送索引文档请求
  2. Node1 根据文档ID(_id字段)计算出该文档应该属于shard0,然后请求路由到Node3的P0分片上
  3. Node3在P0上执行了请求。如果请求成功,则将请求并行的路由至Node1,Node2的R0上。当所有的Replicas报告成功后,Node3向请求的Node(Node1)发送成功报告,Node1再报告至Client。

当客户端收到执行成功后,操作已经在Primary shard和所有的replica shards上执行成功了

 

2.5.1 Shards文档路由

当你对一个文档建立索引时,它仅存储在一个primary shard上。ES是怎么知道一个文档应该属于哪个shard?当你创建一个新的文档时,ES是怎么知道应该把它存储至shard1还是shard2? 这个过程不能随机无规律的,因为以后我们还要将它取出来。它的路由算法是:

shard = hash(routing) % numberofprimary_shards

routing的值可以是文档的id,也可以是用户自己设置的一个值。hash将会根据routing算出一个数值然后%primaryshards的数量。这也是为什么primary_shards在index创建时就不能修改的原因。

问题:当看到这里时,产生了一个问题:ES为什么要这样设计路由算法,这样就强制使primaryshards不可变,不利于以后index的扩容,除非事前就要对数据规模有所评估来设计可扩展的index。为什么不能使用一致性hash解决primaryshards改变时的情况呢?

2.6 SHARD

2.6.4更新持久化

不使用fsync将数据flush到磁盘,我们不能保障在断电后或者进程死掉后数据不丢失。ES是可靠的,它可以保障数据被持久化到磁盘。 在2.6.2中,一个完全的提交会将segments写入到磁盘,并且写一个提交点,列出所有已知的segments。当ES启动或者重新打开一个index时,它会利用这个提交点来决定哪些segments属于当前的shard。 如果在提交点时,文档被修改会怎么样?不希望丢失这些修改:

1.当一个文档被索引时,它会被添加到in-memory buffer,并且添加到Translog日志中,见Figure21.

图片 2

2.refresh操作会让shard处于Figure22的状态:每秒中,shard都会被refreshed:

图片 3

在in-memory buffer中的文档会被写入到一个新的segment,但没有fsync。

in-memory buffer被清空

3.这个过程将会持续进行:新的文档将被添加到in-memory buffer和translog日志中,见Figure23

图片 4

4.一段时间后,当translog变得非常大时,索引将会被flush,新的translog将会建立,一个完全的提交进行完毕。见Figure24

图片 5

在in-memory中的所有文档将被写入到新的segment

内核文件系统会被fsync到磁盘。

旧的translog日志被删除

translog日志提供了一个所有还未被flush到磁盘的操作的持久化记录。当ES启动的时候,它会使用最新的commit point从磁盘恢复所有已有的segments,然后将重现所有在translog里面的操作来添加更新,这些更新发生在最新的一次commit的记录之后还未被fsync。

translog日志也可以用来提供实时的CRUD。当你试图通过文档ID来读取、更新、删除一个文档时,它会首先检查translog日志看看有没有最新的更新,然后再从响应的segment中获得文档。这意味着它每次都会对最新版本的文档做操作,并且是实时的。

修改Searcher对象默认的更新时间

Searcher对象的默认更新时间可以通过使用index.refresh_interval参数来修改,该参数无论是添加到ElasticSearch的配置文件中或者使用update settings API都可以生效。例如:

curl -XPUT localhost:9200/test/_settings -d '{
    "index" : {
        "refresh_interval" : "5m"
    }
}'

上面的命令将使Searcher每5秒钟自动更新一次。请记住在更新两个时间点之间添加到索引的数据对查询是不可见的。

图片 6

 

图片 7

Elasticsearch索引的精髓:一切设计都是为了提高搜索的性能。

总结

  本篇从索引的创建操作和原理等方面介绍了ES索引的一些内容,很多都来自各位大神的总结。经过使用ES越来越多开始作为数据库的辅助。希望大家多多指点。

2.4 容灾

ES可以容下当节点宕机情况下的异常。例如现在我们杀掉Node1节点。见Figure6

图片 8

我们杀掉的是master节点。一个Cluster必须要有master以保证集群的功能正常。所以集群要做的第一件事是选择一个新的master:Node2. 当我们杀掉1节点时,Primary shards 1和2丢失了。如果丢失了primary shard,index(名词)将不能正常的工作。此时P1和P2的拷贝存在Node2和Node3上。所以此时新升级的master(Node2)将做的第一件事就是将NODE2和NODE3上的replica shard1和replica shard2升级为primary shard。此时如果我们杀掉NODE2,整个集群的容灾过程同理,还是可以正常运行。

这时,如果我们重启了NODE1,cluster将会重新分配缺少的两个replica shards(现在每个primary shard只有2个replicas,配置是3个,缺少2个)。如果NODE1的数据是旧的,那么它将会继续利用它们,NODE1只会从现在的Primary Shards拷贝这期间更改的数据。

删除和更新

segments是不变的,所以文档不能从旧的segments中删除,也不能在旧的segments中更新来映射一个新的文档版本。取之的是,每一个提交点都会包含一个.del文件,列举了哪一个segmen的哪一个文档已经被删除了。 当一个文档被”删除”了,它仅仅是在.del文件里被标记了一下。被”删除”的文档依旧可以被索引到,但是它将会在最终结果返回时被移除掉。

文档的更新同理:当文档更新时,旧版本的文档将会被标记为删除,新版本的文档在新的segment中建立索引。也许新旧版本的文档都会本检索到,但是旧版本的文档会在最终结果返回时被移除。

2.2 创建一个索引—index,shard,cluster

将数据添加到ES的前提是,我们需要一个索引(名词):index——一个存储与这个索引相对应数据的地方。实际上,index仅仅只是一个命名空间来指向一个或多个实际的物理分片(shard)。

一个分片(shard)是一个比较低层的工作单元来处理这个索引(index)的所有数据的一个切片(slice)。一个shard实际上是一个Lucene实例,在它的能力范围内拥有完整的搜索功能(在处理它自己拥有的数据时有所有的功能)。我们所有文档的索引indexed(动词)和存储工作都是在shard上,但这是透明的,我们不需要直接和shard通信,而是和我们创建的index(名词)通信。

shards是ES将数据分布式在你的集群的关键。想象下shards是数据的容器,文档存储在shards里,而shards被分配在集群的每一个节点Node里。当你的集群规模增长和降低时,ES会自动的在Nodes间迁移shards以保持集群的负载均衡。

shard的分类与作用:

shard可分为primary shard和replica shard。 在一个index里的每一个文档都属于一个单独的primary shard,所以primary shard的数量决定了你最大能存储的数据量(对应于一个index)。

注意:shard是归属与index的,而不是cluster的。

replica shard是primary shard的拷贝。replica有两个作用: 1.冗余容灾 2.提供读请求服务,例如搜索或读取文档

primary shard的数量在索引创建时确定后不能修改,replica可以在任何时候修改。 例: 见Figure2,在2.1的集群上创建一个index,拥有3个primary shards以及1个replica shards。

图片 9

由于只有一台Node,而Primary shard的Replicas与其在同一台节点上毫无意义,所以集群没有初始化replicas,这时添加另外一台Node。见Figure3,每一个primary shard初始化了一个replica。

图片 10

近实时搜索,段数据刷新,数据可见性更新和事务日志

理想的搜索解决方案是这样的:新的数据一添加到索引中立马就能搜索到。第一眼看上去,这不正是ElasticSearch的工作方式吗,即使是多服务器环境也是如此。但是真实情况不是这样的(至少现在不是),后面会讲到为什么它是似是而非。首先,我们往新创建的索引中添加一个新的文档,命令如下:

curl -XPOST localhost:9200/test/test/1 -d '{ "title": "test" }'

接下来,我们在替换文档的同时查找该文档。我们用如下的链式命令来实现这一点:

curl -XPOST localhost:9200/test/test/1 -d '{ "title": "test2" }' ; curl
localhost:9200/test/test/_search?pretty

上面命令的结果类似如下:

{"ok":true,"_index":"test","_type":"test","_id":"1","_version":2}
{
    "took" : 1,
    "timed_out" : false,
        "_shards" : {
        "total" : 5,
        "successful" : 5,
        "failed" : 0
    },
    "hits" : {
        "total" : 1,
        "max_score" : 1.0,
        "hits" : [ {
            "_index" : "test",
            "_type" : "test",
            "_id" : "1",
            "_score" : 1.0, "_source" : { "title": "test" }
        } ]
    }
}

第一行是第一个命令,即索引命令的返回结果。可以看到,数据更新成功。因此,第二个命令,即查询命令查询到的文档title域值应该为test2。但是,可以看到结果并不如人所愿。这背后发生了什么呢?

在揭开前一个问题的答案之前,我们先退一步,来了解底层的Apache Lucene工具包是如何让新添加的文档对搜索可见的。

图片 11

本节将解决以下问题:
  • 为什么搜索是实时的
  • 为什么文档的CRUD操作是实时的
  • ES怎么保障你的更新在宕机的时候不会丢失
  • 为什么删除文档不会立即释放空间

    #### 2.6.1不变性

写到磁盘的倒序索引是不变的:自从写到磁盘就再也不变。 这会有很多好处:

不需要添加锁。如果你从来不用更新索引,那么你就不用担心多个进程在同一时间改变索引。
一旦索引被内核的文件系统做了Cache,它就会待在那因为它不会改变。只要内核有足够的缓冲空间,绝大多数的读操作会直接从内存而不需要经过磁盘。这大大提升了性能。
其他的缓存(例如fiter cache)在索引的生命周期内保持有效,它们不需要每次数据修改时重构,因为数据不变。
写一个单一的大的倒序索引可以让数据压缩,减少了磁盘I/O的消耗以及缓存索引所需的RAM。

当然,索引的不变性也有缺点。如果你想让新修改过的文档可以被搜索到,你必须重新构建整个索引。这在一个index可以容纳的数据量和一个索引可以更新的频率上都是一个限制。

2.5 分布式文档存储

本文由金沙澳门官网发布于数据库信息,转载请注明出处:深入理解索引原理

关键词: 金沙澳门官网

上一篇:Redis的基本操作,基础知识
下一篇:没有了