elasticsearch 大集群,双重别名，滚动更新分词方案

elasticsearch 滚动更新分词

国内用ik、hanlp、ansj或基于其二次开发的比较多

必然有分词变更的操作(主要是是加词)

reindex+别名可以解决一部分问题，但在大集群上会影响业务

elasticsearch写入数据时会对原始数据作分词，检索时会对查询条件作分词，以两次的分词算匹配度打分

以加词为例

加词后会导致数据大幅波动(因为查询语句的的分词结果变了，但原始数据的分词信息并没有变，同样一条查询条件，在加词前后的结果并不一致)，影响产品应用和聚合统计结果，
轻微的波动，可以解释为正常产品优化，导致50%以上甚至100%的数据波动，很难向用户解释

加词只是导致数据波动的一个最常见的原因，更改了原生的分词算法，也会导致这种结果

因此动态加词，热更新不适于这种场景

而常见的reindex+别名操作，不适合reindex耗时严重的大数据集群

常规的静态加词(把新增词加入es ik plugin要求的目录下，或直接打进jar包)需要

1暂停服务

2更新词包

3滚动更新节点(使新增词生效)，恢复es服务,这里可以恢复es服务，但恢得后会有数据波动问题存在

4重建历史索引

理论上很简单，但只限于数据量很小的情况下，提前通知，暂停个小半天维护或选择非工作日也能说得过去

数据量极大的情况下，重建历史索引耗时数周，影响正常使用，一般在国庆和春节这种长假期操作

es集群为基础服务团队维护，长久以来基本也是这种操作,基础服务团队通常只提供一个通用的解决方案，不会根据业务场景作优化调整，也不清楚产品和业务上的痛点

之前由导致的数据波动问题，严重的由专人负责，通过调整查询规则，减少波动的影响，不严重的就完全没人负责

该方案毕竟不可控，以前这里由运维统一负责，个人也懒得花心思，年前公司有放出风来要由产品线接手，个人也不想总这么折腾，就得想办法解决

实际办法很简单，没有任何技术难度，只是些应用技巧

之所以有数据波动是因为同一个analyzer加词前后行为不一致，让analyzer保持一致就可以了，索引时分词和查询时分词用的算法一致，就不会有波动问题

 

以ik的ik_max_word为例

{
"properties": {
"content": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_max_word"
}
}

}'

前后不一致只是因为ik_max_word的行为变了，但更新词包又不是必须要变更ik_max_word

重建索引，是用加词后的analyzer重建，而并不是一定要用ik_max_word来实现