引言

很多认为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

结果如下图

es分片越多越好吗 es 分片大小_elasticsearch

可以很清楚的看到，主分片和副本分片虽然文档数量都是4，但是大小一个是15.7KB，一个是11.9KB。前面说了原因，是因为主副分片中的segment数量不一样导致的。我们来证实下。

使用cat/segment命令来查看分片的segment信息，

GET _cat/segments/my_blog?v

结果如下图

es分片越多越好吗 es 分片大小_es分片越多越好吗_02

从结果中可以很明显看出副本分片上的segment数量比主分片少了一个。这就是造成数据大小不一样的“真凶”。

通常情况下，这种不一致并没有什么影响。ES会帮我们自动处理好分片上segment的数量。当然我们也可以通过ES的force merge命令，强制把分片上的segment合并成指定的数量。

POST my_blog/_forcemerge?max_num_segments=1

max_num_segments 参数用来指定最终要合到的segment数量。

通过上面这个命令，我们强制索引合并segment到一个。然后再次用cat/segment看下分片信息，

es分片越多越好吗 es 分片大小_elasticsearch_03

这样我们的主副分片都只有一个segment了。大小自然是一样的。

知识延伸

ES在写入(index)数据的时候，是先写入到缓存中。这时候数据还不能被搜索到。默认情况下ES每隔1秒会执行refresh操作，从内存buffer中将数据写入os cache(操作系统的内存)，产生一个segment file文件。同时建立倒排索引，这个时候文档是可以被搜索到的。

每次refresh都会生成一个新的segment，那么segment的数量很快就会爆炸。另外就是每次搜索请求都必须访问segment，理论上segment越多，搜索请求就会变的越慢。

ES有一个后台进程专门负责segment的合并，它会把小segments合并成更大的segments。这个merge操作大部分时候我们并不需要关心，ES自动处理什么时候merge。只要不影响查询性能，我们也不需要关系分片上有多少个segment。

es分片越多越好吗 es 分片大小_segment_04

es分片越多越好吗 es 分片大小_ES_05

不过对于一些业务场景，索引是按照天，周，或者月建立的，如果一些老的索引已经停止写入或者更新，我们可以通过执行一次force merge来强制该索引合并到一个大的segment上，提高搜索的效率。