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

elasticsearch 滚动更新分词

公司舆情数据重度依赖 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来实现