es索引有哪几种常见状态的

ES新手入门学习的时候，经常会和MySQL做对比，一个索引可以理解为一个数据库，分片就可以理解为一张表被分割了shards_numbers - 1次，文档类型为type类型，在高版本中在逐渐被剔除。

ES官方也给出了答案：作者不希望不同类型的相同字段在同一个Lucene中。



索引的状态有：红色、**、绿色和黑色四种（ES插件可以看出来）。

green：健康状态，代表所有的主分片和副本分片都可用；

yellow：所有的主分片可用，部分副本分片不可用；

red：部分主分片不可用；

black：索引处于关闭状态，不对外进行交互，一般磁盘空间不足时ES会自动设置。

ES是一款近实时的搜索引擎，而非实时的搜索引擎。ES每秒产生一个新分段，新段先写入文件系统缓存（对读取可见），稍后再执行刷盘 *** 作。由于新段不会立即刷盘，这个过程如果出现意外情况，存在数据丢失的风险，通常做法是记录事务日志。

分片的目的不只是为了分割巨大的索引，还可以并发读。一个索引包含多个分片，一个分片是一个Lucene索引，一个Lucene索引又由很多分段组成，每一个分段都是一个倒排索引。

段合并：ES会选择大小相似的段进行合并，ES每次refersh都会生成一个Lucene段，每次查询都会轮流检查每一个段，查询完对结果进行合并，段越多，搜索也就越慢。由于分段的不变性（访问不需要加锁），更新删除 *** 作本质是标记删除，在段合并的过程中，标记删除的数据并不会写入到新段中，这样就达到了删除的目的。写 *** 作先写Lucene段，再写translog，如果先写translog，写入Lucene段失败，则还需要对translog进行回滚处理。

ES的只读和删除设置，是对索引和磁盘的一种保护机制，当然也可以手动设置索引的只读和删除，以下是ES自动触发的：



索引的别名 *** 作，比如要对一个月的所有索引（每天创建一个索引）进行处理，就可以为索引创建别名，一个索引可以有多个别名，一个别名也可以指向多个索引。

数据库

文章转载自李宇涛L，如果涉嫌侵权，请发送邮件至：contact@modbpro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。



相关阅读

202

es数据库优缺点为。

1、优点：速度快，ES是专门为文本搜索而设计的，使用者可以通过简单的API查询所需文档并得到响应；可扩展，ES可以轻松地分配分布在多个节点上的数据和 *** 作，用户可以轻松地扩展并提高性能；可靠性高，ES可以水平扩展，包括自动集群和d性搜索等功能，具有优秀的故障转移和恢复能力；易用性好，ES使用RESTAPI进行交互，具有良好的可 *** 作性和易部署性。

2、缺点：数据安全性差，ES对数据的安全性要求需要用户自己保障，需配置好权限控制等安全规则；硬盘容量占用方面ES不支持动态裁剪，它将在硬盘中占用更多的空间，并且无法自动删除过期的数据；ES的排名算法相对简单，缺乏语义分析等高级特征。

最原始的ES版本里，必须等待fsync将segment刷入磁盘，才能将segment打开供search使用，这样的话，从一个document写入到它可以被搜索，可能会超过一分钟，主要瓶颈是在fsync实际发生磁盘IO写数据进磁盘，是很耗时的，这就不是近实时的搜索了。为此，引入refresh *** 作的目的是提高ES的实时性，使添加文档尽可能快的被搜索到，同时又避免频繁fsync带来性能开销，依靠的原理就是文件系统缓存OS cache里缓存的文件可以被打开(open/reopen)和读取，而这个os cache实际是一块内存区域，而非磁盘，所以 *** 作是很快的。

写入流程改进：

1）数据写入到内存buffer队列中

2）每隔一定时间，buffer中的数据被写入segment文件，然后先写入os cache

3）只要segment数据写入os cache，那就直接打开segment供search使用，而不必调用fsync将segment刷新到磁盘

将缓存数据生成segment后刷入os cache，并被打开供搜索的过程就叫做refresh，默认每隔1秒。也就是说，每隔1秒就会将buffer中的数据写入一个新的index segment file，先写入os cache中。所以，es是近实时的，输入写入到os cache中可以被搜索，默认是1秒，所以从数据插入到被搜索到，最长是1秒（可配）。

但是，需要注意， index segment刷入到os cache后就可以打开供查询，这个 *** 作是有潜在风险的，因为os cache中的数据有可能在意外的故障中丢失，而此时数据必备并未刷入到os disk，此时数据丢失将是不可逆的，这个时候就需要一种机制，可以将对es的 *** 作记录下来，来确保当出现故障的时候，已经落地到磁盘的数据不会丢失，并在重启的时候可以从 *** 作记录中将数据恢复过来。elasticsearch提供了translog来记录这些 *** 作，结合os cached segments数据定时落盘来实现数据可靠性保证（flush）。

当向elasticsearch发送创建document文档添加请求的时候，document数据会先进入到buffer，与此同时会将 *** 作记录在translog之中，当发生refresh时（数据从index buffer中进入filesystem cache的过程）translog中的 *** 作记录并不会被清除，而当数据从os cache中被写入磁盘之后才会将translog中清空。这个将os cache的索引文件(segment file)持久化到磁盘的过程就是flush，flush之后，这段translog的使命就完成了，因为segment已经写入磁盘，就算故障也可以从磁盘的segment文件中恢复。flush的时机可能是1定时flush；2translog大小达到阈值；3一些重要 *** 作;4指令触发。

translog记录的是已经在内存生成(segments)并存储到os cache但是还没写到磁盘的那些索引 *** 作（注意，有一种解释说，添加到buffer中但是没有被存入segment中的数据没有被记录到translog中，这依赖于写translog的时机，不同版本可能有变化，不影响理解），此时这些新写入的数据可以被搜索到，但是当节点挂掉后这些未来得及落入磁盘的数据就会丢失，可以通过trangslog恢复。

当然translog本身也是磁盘文件，频繁的写入磁盘会带来巨大的IO开销，因此对translog的追加写入 *** 作的同样 *** 作的是os cache，因此也需要定时落盘（fsync）。translog落盘的时间间隔直接决定了ES的可靠性，因为宕机可能导致这个时间间隔内所有的ES *** 作既没有生成segment磁盘文件，又没有记录到Translog磁盘文件中，导致这期间的所有 *** 作都丢失且无法恢复。

translog的fsync是ES在后台自动执行的，默认是每5秒钟主动进行一次translog fsync，或者当translog文件大小大于512MB主动进行一次fsync，对应的配置是indextranslogflush_threshold_period 和 indextranslogflush_threshold_size。还需指出的是， 从ES20开始，每次index、bulk、delete、update完成的时候也会触发translog flush，当flush到磁盘成功后才给请求端返回 200 OK。这个改变提高了数据安全性，但是会对写入的性能造成不小的影响，因此在可靠性要求不十分严格且写入效率优先的情况下，可以在 index template 里设置如下参数："indextranslogdurability":"async"，这相当于关闭了index、bulk等 *** 作的同步flush translog *** 作，仅使用默认的定时刷新、文件大小阈值刷新的机制，同时可以调高 "indextranslogsync_interval":30s (默认是5s)和indextranslogflush_threshold_size配置选项。

整个项目可以共用一个BulkProcessor，可以配置多种刷新策略，将数据由内存刷新到es中。

当设置 OpTypeCREATE 时相同id插入异常看出，es进行了乐观锁控制并发写冲突。

由于设置了BulkProcessor对象，可以将数据设置到 BulkProcessor 对象中，根据策略批量的刷新到Es中。

更新 *** 作传入的doc为map对象，而不是json字符串，否则会抛出异常。

以上就是关于es索引有哪几种常见状态的全部的内容，包括:es索引有哪几种常见状态的、es数据库优缺点、ES中Refresh和Flush的区别等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！