Elasticsearch里面的segment合并

ゝ一世哀愁。 2022-04-06 12:42 270阅读 0赞

通过前面的文章，我们已经知道在elasticsearch中每个shard每隔1秒都会refresh一次，每次refresh都会生成一个新的segment，按照这个速度过不了多久segment的数量就会爆炸，所以存在太多的segment是一个大问题，因为每一个segment都会占用文件句柄，内存资源，cpu资源，更加重要的是每一个搜索请求都必须访问每一个segment，这就意味着存在的segment越多，搜索请求就会变的更慢。  
  
  
那么elaticsearch是如何解决这个问题呢？ 实际上elasticsearch有一个后台进程专门负责segment的合并，它会把小segments合并成更大的segments，然后反复这样。在合并segments的时候标记删除的document不会被合并到新的更大的segment里面，所有的过程都不需要我们干涉，es会自动在索引和搜索的过程中完成，合并的segment可以是磁盘上已经commit过的索引，也可以在内存中还未commit的segment：  
  
（1）在索引时refresh进程每秒会创建一个新的segment并且打开它使得搜索可见  
  
（2）merge进程会在后台选择一些小体积的segments，然后将其合并成一个更大的segment，这个过程不会打断当前的索引和搜索功能。  
  
\[img\]https://www.elastic.co/guide/en/elasticsearch/guide/master/images/elas\_1110.png\[/img\]  
  
  
（3）一旦merge完成，旧的segments就会被删除，流程如下：

````
    3.1 新的segment会被flush到磁盘
    
    3.2 然后会生成新的commit point文件，包含新的segment名称，并排除掉旧的segment和那些被合并过的小的segment
    
    3.3 接着新的segment会被打开用于搜索
    
    3.4 最后旧的segment会被删除掉
    ````

\[img\]https://www.elastic.co/guide/en/elasticsearch/guide/master/images/elas\_1111.png\[/img\]  
  
  
至此原来标记伪删除的document都会被清理掉，如果不加控制，合并一个大的segment会消耗比较多的io和cpu资源，同时也会搜索性能造成影响，所以默认情况下es已经对合并线程做了资源限额以便于它不会搜索性能造成太大影响。  
  
api如下：

````
    PUT /_cluster/settings
    {
       
        "persistent" : {
       
            "indices.store.throttle.max_bytes_per_sec" : "100mb"
        }
    }
    ````

或者不限制：

````
    PUT /_cluster/settings
    {
       
        "transient" : {
       
            "indices.store.throttle.type" : "none" 
        }
    }
    ````

es的api也提供了我们外部发送命令来强制合并segment，这个命令就是optimize，它可以强制一个shard合并成指定数量的segment，这个参数是：max\_num\_segments ，一个索引它的segment数量越少，它的搜索性能就越高，通常会optimize成一个segment。需要注意的是optimize命令不要用在一个频繁更新的索引上面，针对频繁更新的索引es默认的合并进程就是最优的策略，optimize命令通常用在一个静态索引上，也就是说这份索引没有写入操作只有查询操作的时候是非常适合用optimize来优化的，比如说我们的一些日志索引，基本都是按天，周，或者月来索引的，只要过了今天，这周或这个月就基本没有写入操作了，这个时候我们就可以通过optimize命令，来强制合并每个shard上索引只有一个segment，这样查询性能就能大大提升，api如下：

````
    POST /logstash-2014-10/_optimize?max_num_segments=1 
    ````

注意，由外部发送的optimize命令是没有限制资源的，也就是你系统有多少IO资源就会使用多少IO资源，这样可能导致某一段时间内搜索没有任何响应，所以如果你计划要optimize一个超大的索引，你应该使用shard allocation功能将这份索引给移动到一个指定的node机器上，以确保合并操作不会影响其他的业务或者es本身的性能。  
  
\[b\]\[color=green\]\[size=large\] 有什么问题可以扫码关注微信公众号：我是攻城师(woshigcs)，在后台留言咨询。 技术债不能欠，健康债更不能欠， 求道之路，与君同行。 \[/size\]\[/color\]\[/b\] \[img\]http://dl2.iteye.com/upload/attachment/0104/9948/3214000f-5633-3c17-a3d7-83ebda9aebff.jpg\[/img\]