分片大小不均问题
很多认为Elasticsearch(以下简称ES)，同一个分片的主分片和副本分片文档数量肯定是一样的，数据大小也是一样的。
文档数量并非完全相等，数据大小也不一定一样。
产生这种现象的原因在于，主分片和副本分片的segment数量可能不一样。
演示
新建索引，插入数据，版本es，7.10
PUT stuinfo
PUT stuinfo/dosc/_mapping
{
"properties": {
"id": {"type": "long"},
"name": {"type": "text"},
"age": {"type": "long"},
"addr": {"type": "text"}
}
}
PUT stuinfo/_bulk
{"index":{"_id":"1"}}
{"id":572553,"name":"xiaoming","age":"22","addr":"addr1"}
{"index":{"_id":"2"}}
{"id":572554,"name":"xiaowang","age":"23","addr":"addr2"}
{"index":{"_id":"3"}}
{"id":572555,"name":"xiaoliu","age":"21","addr":"addr3"}
然后使用cat/shards命令看下索引的分片信息
GET _cat/shards/stuinfo
可以看到size大小并不一致
GET _cat/segments/stuinfo?v
可以看到主分片有两个segement，导致了主副本分片大小不一致
force merge
强制把分片上的segment合并成指定的数量
POST stuinfo/_forcemerge?max_num_segments=1
通过上面这个命令，我们强制索引合并segment到一个。然后再次用cat/segment看下分片信息，大小就一致了。
段合并
https://blog.csdn.net/u010454030/article/details/79629400
段是lucene组织数据的单位
实际上elasticsearch有一个后台进程专门负责segment的合并，它会把小segments合并成更大的segments，然后反复这样。在合并segments的时候标记删除的document不会被合并到新的更大的segment里面，所有的过程都不需要我们干涉，es会自动在索引和搜索的过程中完成，合并的segment可以是磁盘上已经commit过的索引，也可以在内存中还未commit的segment。
索引段粒度越小，查询性能越低且耗费的内存越多。频繁的文档更改操作会导致大量的小索引段，从而导致文件句柄打开过多的问题，如修改系统配置，增大系统允许的最大文件打开数。总的来讲，当索引段由多一个合并为一个的时候，会减少索引段的数量从而提高ES性能。
段会在 Refresh Interval 的时候产生，如果我们对实时性要求不高的情况下，我们可以适当调整刷新的时间间隔为 分钟级别，甚至在大量的同步数据，和写数据的时候，可以设置为 -1
我们可以通过以下操作，对段进行合并。
主副shard的doc数量不一致的原因
造成主副shard的doc数量不一致的原因有很多，例如以下两种情况：
- 如果一直有doc写入shard，由于主副数据同步有一定延迟，会导致数据不一致。但一般停止写入后，主副doc数量是一致的。
- 如果使用自动生成docid的方式写入doc，由于主shard写入完成后会转发请求到副shard，因此在此期间，如果执行了删除操作，例如并行发送Delete by Query请求删除了主分片上刚写完的doc，那么副shard也会执行此删除请求；然后主shard又转发写入请求到副shard上，对于自动生成的id，doc将直接写入副shard，不进行检查，最终导致主副shard的doc数量不一致，同时在
doc.delete中也可以看到主shard中存在大量的删除文档。