一.ES中删除/修改分析
- ElasticSearch执行删除操作时，ES先标记文档为deleted状态，而不是直接物理删除。当ES存储空
间不足或工作空闲时，才会执行物理删除操作。 - ElasticSearch执行修改操作时，ES 不会真的修改Document中的数据，而是标记ES中原有的文档
为deleted状态，再创建一个新的文档来存储数据。
二.ES优化
ES的优化即通过调整参数使得读写性能更快
1.磁盘选择
磁盘通常是服务器的瓶颈。Elasticsearch重度使用磁盘，磁盘的效率越高，Elasticsearch的执行效率就越高。这里有一些优化磁盘的技巧：
- 使用SSD（固态硬盘），它比机械磁盘优秀多了。
- 使用RAID0模式（将连续的数据分散到多个硬盘存储，这样可以并行进行IO操作）,代价是一块硬盘发生故障就会引发系统故障。
- 不要使用远程挂载的存储。
2.分片策略
分片和副本数并不是越多越好。每个分片的底层都是一个Lucene索引，会消耗一定的系统资源。且搜索请求需要命中索引中的所有分片，分片数过多会降低搜索性能。索引的分片数需要架构师和技术人员对业务的增长有预先的判断，一般来说我们遵循以下原则：
- 每个分片占用的硬盘容量不超过ES的最大JVM的堆空间设置(一般设置不超过32G）。比如：如果索引的总容量在500G左右，那分片数量在16个左右即可。
- 分片数一般不超过节点数的3倍。比如：如果集群内有10个节点，则分片数不超过30个。
- 推迟分片分配：节点中断后集群会重新分配分片。但默认集群会等待一分钟来查看节点是否重新加入。我们可以设置等待的时长，减少重新分配的次数：
PUT /索引/_settings
{
"settings":{
"index.unassianed.node_left.delayed_timeout":"5m"
}
}
- 减少副本数量：进行写入操作时，需要把写入的数据都同步到副本，副本越多写入的效率就越慢。
我们进行大批量进行写入操作时可以先设置副本数为0，写入完成后再修改回正常的状态。
3. 内存设置
ES默认占用内存是4GB，我们可以修改config/jvm.option设置ES的堆内存大小，Xms表示堆内存的初始大小，Xmx表示可分配的最大内存。
- Xmx和Xms的大小设置为相同的，可以减轻伸缩堆大小带来的压力。
- Xmx和Xms不要超过物理内存的50%，因为ES内部的Lucene也要占据一部分物理内存。
- Xmx和Xms不要超过 32GB，由于Java语言的特性，堆内存超过32G会浪费大量系统资源，所以在内存足够的情况下，最终我们都会采用设置为31G：
-Xms 31g
-Xmx 31g
例如：在一台128GB内存的机器中，我们可以创建两个节点，每个节点分配31GB内存。
