引言
很多认为Elasticsearch(以下简称ES)，同一个分片的主分片和副本分片文档数量肯定是样的，数据大小也是一样的。
这个其实值说对了一半，文档数量是一样的没错，但是数据大小不一定一样。
产生这种现象的原因在于，主分片和副本分片的segment数量可能不一样。
正文
我们来看个示例。
以下的示例测试环境是ES 7.1.0版本
先插入4个文档，
PUT my_blog/_doc/1
{
"title" : "blog1",
"content" : "this is blog1"
}
PUT my_blog/_doc/2
{
"title" : "blog2",
"content" : "this is blog2"
}
PUT my_blog/_doc/3
{
"title" : "blog3",
"content" : "this is blog3"
}
PUT my_blog/_doc/4
{
"title" : "blog4",
"content" : "this is blog4"
}
然后使用cat/shards命令看下索引的分片信息，
GET _cat/shards/my_blog?v
结果如下图
可以很清楚的看到，主分片和副本分片虽然文档数量都是4，但是大小一个是15.7KB，一个是11.9KB。前面说了原因，是因为主副分片中的segment数量不一样导致的。我们来证实下。
使用cat/segment命令来查看分片的segment信息，
GET _cat/segments/my_blog?v
结果如下图
从结果中可以很明显看出副本分片上的segment数量比主分片少了一个。这就是造成数据大小不一样的“真凶”。
通常情况下，这种不一致并没有什么影响。ES会帮我们自动处理好分片上segment的数量。当然我们也可以通过ES的force merge命令，强制把分片上的segment合并成指定的数量。
POST my_blog/_forcemerge?max_num_segments=1
max_num_segments 参数用来指定最终要合到的segment数量。
通过上面这个命令，我们强制索引合并segment到一个。然后再次用cat/segment看下分片信息，
这样我们的主副分片都只有一个segment了。大小自然是一样的。
知识延伸
ES在写入(index)数据的时候，是先写入到缓存中。这时候数据还不能被搜索到。默认情况下ES每隔1秒会执行refresh操作，从内存buffer中将数据写入os cache(操作系统的内存)，产生一个segment file文件。同时建立倒排索引，这个时候文档是可以被搜索到的。
每次refresh都会生成一个新的segment，那么segment的数量很快就会爆炸。另外就是每次搜索请求都必须访问segment，理论上segment越多，搜索请求就会变的越慢。
ES有一个后台进程专门负责segment的合并，它会把小segments合并成更大的segments。这个merge操作大部分时候我们并不需要关心，ES自动处理什么时候merge。只要不影响查询性能，我们也不需要关系分片上有多少个segment。
不过对于一些业务场景，索引是按照天，周，或者月建立的，如果一些老的索引已经停止写入或者更新，我们可以通过执行一次force merge来强制该索引合并到一个大的segment上，提高搜索的效率。