Elasticsearch相关

1、使用ES须知

ES不是数据库，不是可靠的数据存储系统。ES不是实时系统，数据写入成功只是translog成功，类似mysql的binlog,同理删除数据也不是实时的。其实ES内部有一个后台线程，定时将内存的数据写入到存储引擎中。当然可以写入数据后refresh,但是会重新打开所有索引文件，需要解压和刷缓存等等，性能影响极大。ES不是一个强一致性的系统。也就是说同样的query多次查询的数据可能会不一致。由于shard的主分片和副本是由独立的节点去刷新的，刷新的频率并不同步，这样同样的query发送到不同的分片(主片和从片)上看到的数据是不同的，导致的结果是查询到的数据也不完全同步。简单说，ES是一个最终一致性系统

 

2、关于Mappingmapping相当于数据库的表结构，决定了ES在建立倒排索引、进行检索时对文档采取的相关策略，如数字类型、日期类型、文件类型等。在写数据前ES不强制要求创建mapping，因为ES有动态识别和创建的机制，但是非常不建议使用ES的动态识别和创建的机制，因为很多情况下这并非你所需要。推荐的做法是在写数据之前仔细的创建的mapping,mapping不能更新，存在的字段不能被更新和删除，不存在的字段可以添加mapping冲突

 

3、关于容灾机制

ES中的index，首先会进行分片，每一个分片数据一般都会有自己的副本数据，ES分配分片的策略会保证同一个分片数据和自己的副本不会分配到同一个节点上.当集群中的某一节点宕机后，ES的master在ping该节点时通过一定的策略会发现该节点不存活；此时，ES开启恢复过程，恢复的策略如下：恢复的目标是保证集群中分片的副本数不变,恢复的目标是保证集群中分片的副本数不变,如果宕机的节点上承载某分片的主分片，那么此时(恢复过程)会将该分片分配在其他节点上的某一副本提升为主分片(记住：同一分片和其副本总是不在同一节点上，保证有对应的副本可供提升的).根据4.1保证副本数不变，如果宕机的节点承载某分片的副本，那么ES会在其他非宕机节点上用主分片复制一个副本.整个过程不影响集群的读写功能；但是由于多了复制分片和迁移分片的过程，集群的读写性能受影响.

 

4、关于扩容机制

整个过程不影响集群的读写功能，但是由于多了复制分片和迁移分片的过程，集群的读写性能受影响

 

5、ES写入相关

原理参考文档,Es update通过标记删除老文档。并发update同一条document，ES内部采用了乐观并发的处理，并发修改的操作直到最后要提交是才加锁检查版本号，如果发现修改之前获取的版本号已经改变(被修改),那么会抛出这个异常,然后由用户决定如何处理该异常,乐观并发一般适用用读多写少的场景.

 

 

本文参考自以下

https://blog.csdn.net/weixin_39605997/article/details/111218591

https://zhuanlan.zhihu.com/p/34669354

https://www.zhihu.com/column/Elasticsearch