es删除索引数据 es删除索引但是磁盘不释放

怎么用spring获取es数据

5. 如果使用ES提供的jar包访问，需要JDK1.7及以上。

1. ES和solr都是作为全文搜索引擎出现的。都是基于Lucene的搜索。

es删除索引数据 es删除索引但是磁盘不释放

一、写入磁盘后可见：

2. ES不是可靠的存储系统，不是数据库，它有丢数据的风险。

3. ES不是实时系统，数据写入成功只是trans log成功（类似于MySQL的bin log），写入成功后立刻查询查不到是正常的。因为数据此刻可能还在内存里而不是进入存储引擎里。同理，删除一条数据后也不是马上消失。写入何时可查询？ES内部有一个后台线程，定时将内存中的一批数据写入到存储引擎，此后数据可见。默认后台线程一秒运行一次。该线程运行的越频繁，写入性能越低。运行的频率越低，写入的性能越高（不会无限高）。

4. 目前已知的单ES集群可以存储PB级别的数据，不过这个就非常费劲了。TB级别数据没压力。

6. 使用对应的版本访问ES server。如果ES server端的版本是1.7，那么请使用ES 1.7的client。如果ES server是2.1，请使用2.1的client。

7. ES索引存在Linux的文件系统之上（背后是文件系统，不是类通过每秒自动刷新创建新的段，用不了多久段的数量就爆炸了，每个段消费大量文件句柄，内存，cpu资源。更重要的是，每次搜索请求都需要依次检查每个段。段越多，查询越慢。似于HDFS的分布式文件系统）

8. ES Ja client是线程安全的，全局构建一个即可满足读写需求，不要每次都创建ES client。每次访问ES都构建新的es client即会抛出次异常。

9. 非常不建议使用ES的动态识别和创建的机制，因为很多情况下这并非你所需要。的做法是在写数据之前仔细的创建mapping。

10. 强烈不建议在ES中使用深分页。可能会导致集群不可用。

11. ES是静态分片，一旦分片数在创建索引时确定那么后继不能修改。

12. ES里提供了type，很多人以为type是物理表，一个type的数据是存储的；但是在ES内部并不是这样，type在ES内部仅仅是一个字段。所以在很多数据能分为index的情况下，不要放到一个index里用type去分。只有嵌套类和父子类的情况下使用type才是合理的。

13. ES并不提供原生的中文分词的能力。有第三方的中文分词的插件，比如ik等。Ik是个toy分词器，有严肃的分词需求的话，请在使用ES之前使用的分词器分好词后向ES写入。

14. ES中的index，首先会进行分片，每一个分片数据一般都会有自己的副本数据，ES分配分片的策略会保证同一个分片数据和自己的副本不会分配到同一个节点上。当集群中的某一节点宕机后，ES的在ping该节点时通过一定的策略会发现该节点不存活；会开启ES的恢复过程

15. ES没有update的能力。所有的update都是标记删除老文档，然后重新insert一条新文档。

ES近实时搜索原理

3、即时性要求高，：如广告立马需要被看到，需要手动强制刷新

Segment（段）：Lucene里面的一个数据集概念

ES通过后台合并段解决这个问题。ES利用段合并的时机来真正从文件系统删除那些version较老或者是被标记为删除的文档。被删除的文档（或者是version较老的）不会再被合并到新的更大的段中。

提交点文件：有一个列表存放着所有已知的所有段

ES底层是三、 ES对Doc删除的处理基于Lucene，最核心的概念就是Segment(段)，每个段本身就是一个倒排索引。

ES中的Index由多个段的和commit point(提交点)文件组成。

提交点文件中有一个列表存放着所有已知的段，下面是一个带有1个提交点和3个段的Index示意图：

Doc新增提交主要过程如下：

1、Doc写入Buffer

Doc会先被搜集到内存中的Buffer内，这个时候还无法被搜索到，如下图所示：

（1）创建一个新段，作为一个追加的倒排索引，写入到磁盘（文件系统缓存）

（2）将新的包含新段的Commit Point(提交点)写入磁盘（文件系统缓存）

（3）磁盘进行fsync，主要是将文件系统缓存中等待的写入作全部物理写入到磁盘，保证数据不会在发生错误时丢失

（4）这个新的段被开启， 使得段内文档对搜索可见

（5）将内存中buffer清除，又可以把新的Doc写入buffer了

下面展示了这个过程完成后的段和提交点的状态：

为了数据安全，每次的索引变更都要立刻刷盘， 所以 Commit 作意味着将Segment 合并并写入磁盘。保证内存数据尽量不丢。刷盘是很重的 IO 作， 所以为了机器性能和近实时搜索， 并不会刷盘那么及时。

新文档被索引意味着文档会被首先写入内存 buffer 和 translog 文件。每个 shard 都对应一个 translog 文件。

在 elasticsearch 中， _refresh作默认每秒执行一次，意味着将内存 buffer 的数据写入到一个新的Segment 中，这个时候索引变成了可被检索的。

Flush作意味着将内存buffer的数据全都写入新的Segments中，并将内存中所有的Segments全部刷盘，并且清空translog日志的过程。

1、refresh：

Lucene支持对新段写入和打开 - 可以使文档在没有完全刷入硬盘的状态下就能对搜索可见，而且是一个开销较小的作，可以频繁进行。

下面是一个已经将Docs刷入段但还没有完全提交的示意图：

2、translog

为了避免在两次commit作间隔时间发生异常导致Doc丢失，ES中采用了一个事务日志记录每次对ES的作。加上translog后新增文档流程如下：

文档被添加到buffer同时追加到translog，如图：

下面示意图展示了这个状态：

4、flush

flush就是执行commit清空、干掉老translog的过程。默认每个分片30分钟或者是translog过于大的时候自动flush一次。可以通过flush API手动触发，但是只会在重启节点或关闭某个索引的时候这样做，因为这可以让未来ES恢复的速度更快(translog文件更小)。

（1）删除一个ES文档不会立即从磁盘上移除，它只是被标记成已删除。因为段是不可变的，所以文档既不能从旧的段中移除，旧的段也不能更新以反映文档的版本。

ES的做法是，每一个提交点包括一个.del文件（还包括新段），包含了段上已经被标记为删除状态的文档。所以，当一个文档被做删除作，实际上只是在.del文件中将该文档标记为删除，依然会在查询时被匹配到，只不过在最终返回结果之前会被从结果中删除。ES将会在用户之后添加更多索引的时候，在后台进行要删除内容的清理。

（2）Doc删除与段合并的关系

ES对一个不断有数据写入的索引处理流程如下：

索引过程中，refresh会不断创建新的段，并打开它们。

合并过程会在后台选择一些小的段合并成大的段，这个过程不会中断索引和搜索。合并过程如图：

两个已提交的段 和一个未提交的段合并为一个更大的段。从上图可以看到，段合并之前，旧有的Commit和没Commit的小段皆可被搜索。

（3）段合并后的作:

a、新的段flush到硬盘

b、编写一个包含新段的新提交点，并排除旧的较小段。

c、新的段打开供搜索

d、旧的段被删除

合并完成后新的段可被搜索，旧的段被删除，如下图所示：

注：

什么情况下要强制刷新：

1、reindex后，手动修改refresh，由-1（不刷新）改为想要的刷新值

2、在读多，写少时，可以强制不刷新，因为每写入一条数据就会产生一个新段，查询时就会查一次，降低效率