Hi，大家好。今天 INFINI Labs 为大家带来 2023 春节后第一波产品更新发布，欢迎大家免费下载体验使用。

INFINI Gateway v1.9.0

极限网关本次迭代带来了大量的更新如下：

Breaking changes

• Refactoring config for ip access control
• Disable elasticsearch metadata refresh by default
• Update default config path from configs to config
• Remove sample-configs, moved to dedicated integrated-testing project
• Remove field conntime, update field @timestamp to timestamp in logging filter
• Rename disorder to fast

Features

• Support listen on IPv6 address
• Add general health api
• Add request_ip to context
• Add badger filter plugin
• Allow to split produce and consume messages from s3
• Add bulk_request_throttle filter
• Support access request context and more output options in echo filter
• Add body_json to response context
• Add cert config to API module, support mTLS
• Add api to clear scroll context
• Floating_ip support stick by priority
• Add keystore util
• Allow to save success bulk results in bulk_indexing processor
• Enable watch and reload the major config file
• Support run background job in one goroutine
• Allow to handle async_bulk request logging
• Add config to control cluster health check while cluster not available, set default to false
• Allow to follow redirects in http filter, set default read and write timeout to 30s
• Support collect instance metrics to monitoring gateway
• Add json log format

Bug fix

• Fix user was removed in logging filter
• Fix incorrect message size issue, reload when files changed in disk_queue
• Fix issue that index_diff could not finished automatically
• Fix hostname was not well updated in filter set_request_header or set_hostname
• Fix to check consumer’s lag instead of queue’s lag in flow_runner processor
• Fix file not found error for disk_queue
• Fix the delete requests was not proper handled in filter bulk_reshuffle, bulk_request_mutate and bulk_indexing processor
• Fix memory leak caused by misuse of bytes buffer
• Fix to handle the last request in replay processor
• Fix url args was not updated after change
• Fix memory leak when serving high-concurrent requests
• Fix nil id caused error when using sliced workers in bulk_indexing processor
• Fix index name with dot
• Refactoring time fields for orm, skip empty time
• Refactoring stats, allow to register extended stats
• Fix to restart gateway entrypoint on flow change
• Update ratio filter, fix random number, add header to ratio filter
• Fix query parameter no_cache was not well respected in get_cache filter
• Fix single delete request was ignored in bulk requests
• Fix request mutate filter

Improvements

• Remove newline in indexing_merge and json_indexing processor
• Improve instance check, add config to disable
• Add option skip_insecure_verify to s3 module
• Improve instance check, enable config to disable
• Update the way to get ctx process info, optimize memory usage
• Improve indexing performance for bulk_indexing processor
• Refactoring disk_queue, speedup message consumption
• Enable segment compress for disk_queue by default
• Skip download s3 files when s3 was not enabled
• Add option to log warning messages for throttle filters
• Optimize hash performance for getting primary shardID and partitionID
• Add cache for get index routing table
• Optimize performance for bulk response processing
• Refactoring bulk_processor, pass meta info to payload func
• Don’t call payload func for delete action
• Improve queue consumer’s lag check
• Enable prepare flat files ahead for read by default, skip unnecessary file
• Add object pool for xxhash
• Refactoring disk_queue, handle consumer in-flight segments in memory
• Add config to remove duplicated newline for bulk_processor
• Add metric timestamp in stats api
• Improve error on routing table missing
• Refactoring bytes buffer and object pool, expose metrics via API
• Refactoring tasks pooling, support throttle and unified control
• Optimize badger file size and memory usage
• Refactoring time fields for orm, skip empty time
• Refactoring stats, allow to register extended stats
• Refactoring to handle bulk response results
• Add client_session_cache_size to tls setting
• Safety add newline to each bytes when handle bulk requests

INFINI Console v0.7.0

INFINI Console 本次迭代更新如下：

• 新增初始化安装向导；

  

• 新增系统服务健康监控；

• 新增 License 授权；

  

• 新增索引和节点层面数据字节写入吞吐量指标(indexing bytes)；
• 修复了 Discover 第一次加载未发起搜索请求的问题；
• 修复了查看节点线程池指标时选择多个节点后指标不显示的问题；

期待反馈

欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（https://github.com/infinilabs） 中的对应项目中提交 Feature Request 或提交 Bug。

• INFINI Gateway： https://github.com/infinilabs/gateway/issues
• INFINI Console： https://github.com/infinilabs/console/issues
• 下载地址： https://www.infinilabs.com/download/

您还可以通过邮件联系我们：hello@infini.ltd

或者拨打我们的热线电话：(+86) 400-139-9200

也欢迎大家添加微信小助手(INFINI-Labs)拉群交流和学习。

感谢大家的围观，祝大家周末愉快。

• 设计并开发下一代实时搜索引擎 ;
• 持续优化实现方案，改进组件性能 ;
• 保证工程质量和开发效率 。

• 3 年以上搜索引擎开发经验，计算机相关专业，本科及以上学历 ;
• 熟练掌握 Rust/C/C++/Golang 中的一种或多种语言，有 Rust 实际开发经验者优先 ;
• 熟悉 Linux 操作系统，了解Linux系统常用操作命令, 能基于shell编写脚本 ;
• 熟悉 Linux 下内存管理机制，低延迟、高并发无锁化编程 ;
• 熟悉 TCP/IP、Socket、HTTP 等网络协议 ;
• 具有良好的沟通、团队协作能力；
• 熟悉常见分布式算法，有大规模分布式系统开发经验优先；
• 较好的英文阅读和写作能力，具备比较强的逻辑思维能力；
• 良好的编码习惯和技术文档能力，具备持续输出的能力;
• 工作地点不限 。

• 有自己的博客、Github、开源项目优先 ;
• 具有相关搜索引擎开发工作经验者优先 ;
• 熟悉各类索引结构；
• 熟悉 LSM-Tree、B+Tree、RocksDB、LevelDB 优先 ;
• 有较强的学习能力，愿意致力于新技术的研究 。

会议信息同步

1. 关于讲师议题：少部分讲师和议题有变化，组委会近期会与讲师沟通确认是否需要更换新的演讲议题。
2. 已经报名参会者无需再次报名。

其他说明

1. 目前大会报名购票通道已重新开启，欢迎推荐有兴趣的朋友报名参会，可享受八折购票优惠，折扣报名链接：https://www.bagevent.com/event/7899116?discountCode=80OFF
2. 由于部分议题陈旧，我们重新开放了演讲议题申请，欢迎大家提交和推荐。议题提交链接：http://elasticsearch.mikecrm.com/2gQNDKh
3. 赞助合作申请：http://elasticsearch.mikecrm.com/6gxTHs4
4. 如需要加入大会微信交流群，请加微信(lsy965145175)拉群。
5. 更多大会信息请关注官网：https://conf.elasticsearch.cn

感谢

这次的 Elastic 中国开发者大会虽然遇到了很多的困难与波折，但因为您们的理解和支持，一直鼓励着我们，给了我们信心与动力，我们会本着办好中国开发者大会的初心继续前行，再次感谢大家的大力支持！

在2023年新春到来之际，Elastic 中国开发者大会组委会祝大家新春快乐、身体健康、工作顺利、阖家幸福！

原文地址 elasticstack.blog.csdn.net

同义词用于提高搜索质量并扩大匹配范围。 例如，搜索 England 的用户可能希望找到包含 British 或 UK 的文档，尽管这三个词完全不同。

Elasticsearch 中的同义词功能非常强大，如果实施得当，可以使你的搜索引擎更加健壮和强大。 在本文中，我们将通过简单的代码片段介绍在实践中实现同义词功能的要点。 特别是，我们将介绍如何更新现有索引的同义词，这是一个相对高级的话题。

在今天的展示中，我将使用最新的 Elastic Stack 8.6.0，尽管版本不对我们的展示有任何的影响。

准备

我们将使用 Docker 在本地启动一个 Elasticsearch 服务器，并使用 Kibana 来管理索引和运行命令。 如果你以前从未使用过 Elasticsearch 或想快速复习一下，这篇文章可能会对你有所帮助。 如果你在 Docker 中运行 Elasticsearch 时遇到问题，这篇文章很可能会帮助你解决问题。在今天的文章中，我们尝试使用 docker 来部署一个没有安全功能的 Elasticsearch 集群。

准备就绪后，让我们开始探索 Elasticsearch 中的同义词功能的旅程。

我们将在本文中使用的 docker-compose.yaml 文件包含以下内容，稍后我们将向其添加更多功能：

docker-compose.yml

`

1.  version: "3.9"
2.  services:
3.    elasticsearch:
4.      image: elasticsearch:8.6.0
5.      environment:
6.        - discovery.type=single-node
7.        - ES_JAVA_OPTS=-Xms1g -Xmx1g
8.        - xpack.security.enabled=false
9.      volumes:
10.        - type: volume
11.          source: es_data
12.          target: /usr/share/elasticsearch/data
13.      ports:
14.        - target: 9200
15.          published: 9200
16.      networks:
17.        - elastic

19.    kibana:
20.      image: kibana:8.6.0
21.      ports:
22.        - target: 5601
23.          published: 5601
24.      depends_on:
25.        - elasticsearch
26.      networks:
27.        - elastic      

29.  volumes:
30.    es_data:
31.      driver: local

33.  networks:
34.    elastic:
35.      name: elastic
36.      driver: bridge

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

你可以使用以下命令之一启动 Elasticsearch 和 Kibana：

docker-compose up

或者

docker-compose up -d

如果加上 -d 选项的话，Elasticsearch 会以 daemon 的形式来运行。上面是一种最为简单的方式来启动 Elasticsearch 集群及 Kibana。由于它没有设置安全，我们无需输入任何凭证就可以直接进入到 Kibana 了。

使用带有同义词列表的标准同义词 token 过滤器

让我们首先使用带有同义词列表的标准同义词标记过滤器创建一个索引。 在 Kibana 中运行以下命令，我们将在稍后解释详细信息： 

`

1.  PUT synonyms
2.  {
3.    "settings": {
4.      "index": {
5.        "analysis": {
6.          "analyzer": {
7.            "index_analyzer": {
8.              "tokenizer": "standard",
9.              "filter": [
10.                "lowercase",
11.                "synonym_filter"
12.              ]
13.            }
14.          },
15.          "filter": {
16.            "synonym_filter": {
17.              "type": "synonym",
18.              "synonyms": [
19.                "elk => Elastic Stack",
20.                "elkb => Elastic Stack"
21.              ]
22.            }
23.          }
24.        }
25.      }
26.    },
27.    "mappings": {
28.      "properties": {
29.        "name": {
30.          "type": "text",
31.          "analyzer": "index_analyzer"
32.        }
33.      }
34.    }
35.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

这里的要点：

1. 请注意设置键的嵌套级别。 settings => index => analysis => analyzer/filter 都是内置关键字。 但是，index_analyzer 和 synonym_filter 分别是自定义分析器和过滤器的自定义名称。
2. 我们需要创建一个 type 为 synonym 的自定义过滤器。 synonym 选项明确提供了同义词列表。 这通常应该只用于测试，因为更新同义词列表不方便，我们稍后会看到。
3. 本文中使用了 Solr 同义词。 对于此示例，使用了显式映射，这意味着 => 左侧的标记将替换为右侧的标记。 稍后我们将使用等同的同义词，这意味着提供的 token 被等同对待。
4. synonym_filter 添加到名为 index_analyzer 的新自定义分析器的过滤器列表中。 通常过滤器的顺序很重要。 然而，对于同义词过滤器来说，它有点特殊，可能会让我们中的许多人感到惊讶。 在此示例中，即使 synonym_filter 过滤器放在小写过滤器之后，此过滤器返回的标记也会传递给小写过滤器，因此也会变成小写。 因此，你不需要在同义词列表或同义词文件中提供小写 token。
5. 最后，在文档的映射中，为名称字段指定了自定义分析器。

我们知道在早期的 Elastic 产品中 elk 就是 Elastic Stack 的代名词。之后随着 Beats 的加入，很多开发者也把 elkb 当做 Elastic Stack 的代名词。要测试在索引中创建的分析器，我们可以调用 _analyze 端点：

1.  GET /synonyms/_analyze
2.  {
3.    "analyzer": "index_analyzer",
4.    "text": "elk is powerful"
5.  }

上面命令的输出为：

`

1.  {
2.    "tokens": [
3.      {
4.        "token": "elastic",
5.        "start_offset": 0,
6.        "end_offset": 3,
7.        "type": "SYNONYM",
8.        "position": 0
9.      },
10.      {
11.        "token": "is",
12.        "start_offset": 4,
13.        "end_offset": 6,
14.        "type": "<ALPHANUM>",
15.        "position": 1
16.      },
17.      {
18.        "token": "stack",
19.        "start_offset": 4,
20.        "end_offset": 6,
21.        "type": "SYNONYM",
22.        "position": 1
23.      },
24.      {
25.        "token": "powerful",
26.        "start_offset": 7,
27.        "end_offset": 15,
28.        "type": "<ALPHANUM>",
29.        "position": 2
30.      }
31.    ]
32.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

从上面的输出中，我们可以看到 type 为 SNONYM 的 token 为 elastic 及 stack。让我们向索引中添加一些文档并测试它在搜索中是否正常工作：

1.  PUT /synonyms/_doc/1
2.  {
3.    "name": "elk is very powerful"
4.  }

6.  PUT /synonyms/_doc/2
7.  {
8.    "name": "elkb is useful"
9.  }

11.  PUT /synonyms/_doc/3
12.  {
13.    "name": "Elastic Stack is so widely used"
14.  }

我们可以使用 match 关键字进行简单的搜索：

1.  GET /synonyms/_search?filter_path=**.hits
2.  {
3.    "query": {
4.      "match": {
5.        "name": "elk"
6.      }
7.    }
8.  }

如果没有问题，所有三个文件都应该被搜索到：

`

1.  {
2.    "hits": {
3.      "hits": [
4.        {
5.          "_index": "synonyms",
6.          "_id": "2",
7.          "_score": 0.31931418,
8.          "_source": {
9.            "name": "elkb is useful"
10.          }
11.        },
12.        {
13.          "_index": "synonyms",
14.          "_id": "1",
15.          "_score": 0.29086044,
16.          "_source": {
17.            "name": "elk is very powerful"
18.          }
19.        },
20.        {
21.          "_index": "synonyms",
22.          "_id": "3",
23.          "_score": 0.24686477,
24.          "_source": {
25.            "name": "Elastic Stack is so widely used"
26.          }
27.        }
28.      ]
29.    }
30.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

索引时间 vs 搜索时间进行同义词操作

如你所见，在上面的示例中，只创建了一个分析器，它用于索引和搜索。

不鼓励在索引（indexing）步骤中对所有文档应用同义词，因为它有一些主要缺点：

• 如果不重新索引所有内容，就无法更新同义词列表，这在实践中是非常低效的。
• 搜索分数会受到影响，因为同义词 token 也会被计算在内。
• 索引过程变得更加耗时并且索引将变得更大。 对于小数据集来说可以忽略不计，但对于大数据集来说非常重要。

因此，最好在搜索步骤中只应用同义词，这样可以克服所有三个缺点。 为此，我们需要创建一个用于搜索的新分析器。

使用 search_analyzer 并应用搜索时间同义词

在 Kibana 中运行以下命令以创建具有搜索时同义词的新索引：

`

1.  PUT synonym_graph
2.  {
3.    "settings": {
4.      "index": {
5.        "analysis": {
6.          "analyzer": {
7.            "index_analyzer": {
8.              "tokenizer": "standard",
9.              "filter": [
10.                "lowercase"
11.              ]
12.            },
13.            "search_analyzer": {
14.              "tokenizer": "standard",
15.              "filter": [
16.                "lowercase",
17.                "synonym_filter"
18.              ]
19.            }
20.          },
21.          "filter": {
22.            "synonym_filter": {
23.              "type": "synonym_graph",
24.              "synonyms": [
25.                "elk => Elastic Stack",
26.                "elkb => Elastic Stack"
27.              ]
28.            }
29.          }
30.        }
31.      }
32.    },
33.    "mappings": {
34.      "properties": {
35.        "name": {
36.          "type": "text",
37.          "analyzer": "index_analyzer",
38.          "search_analyzer": "search_analyzer"
39.        }
40.      }
41.    }
42.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

关键点：

• 该类型现在更改为 synonym_graph，这是一个更复杂的同义词过滤器，旨在仅用作搜索分析器的一部分。 它可以更恰当地处理多词同义词，推荐用于搜索时分析。 但是，你可以继续使用原来的 synonym 类型，它在这篇文章中的表现是一样的。
• 同义词过滤器从索引时间分析器中删除并添加到搜索时间分析器中。
• search_analyzer 是为 name 字段明确指定的。 如果未指定，则相同的分析器 (index_analyzer) 将用于索引和搜索。

分析器应该返回与以前相同的 token。 然而，当你用这些命令为三个文档建立索引并再次执行相同的搜索后，结果会有所不同：

1.  PUT /synonym_graph/_doc/1
2.  {
3.    "name": "elk is very powerful"
4.  }

6.  PUT /synonym_graph/_doc/2
7.  {
8.    "name": "elkb is useful"
9.  }

11.  PUT /synonym_graph/_doc/3
12.  {
13.    "name": "Elastic Stack is so widely used"
14.  }

我们使用如下的命令来进行搜索：

1.  GET /synonym_graph/_search?filter_path=**.hits
2.  {
3.    "query": {
4.      "match": {
5.        "name": "elk"
6.      }
7.    }
8.  }

这一次，只有如下的结果返回。甚至 “elk is very powerful” 这个文档也没有被返回：

1.  {
2.    "hits": {
3.      "hits": [
4.        {
5.          "_index": "synonym_graph",
6.          "_id": "3",
7.          "_score": 2.3589978,
8.          "_source": {
9.            "name": "Elastic Stack is so widely used"
10.          }
11.        }
12.      ]
13.    }
14.  }

原因是同义词过滤器仅在搜索时应用。 搜索查询 elk 被替换为同义词标记 “Elastic Stack”。 然而，索引中的文档没有被同义词过滤器（synonym_filter）过滤，因此 “elk” 只是被标记为 elk 而没有被 Elastic Stack 替换。 类似于 elkb。 结果，只能匹配 “Elastic Stack is so widely used”。

为了使其像前面的示例一样正常工作，我们需要将同义词规则从显式映射更改为等效同义词。 让我们按如下方式更新同义词过滤器：

1.  ......
2.    "filter": {
3.      "synonym_filter": {
4.        "type": "synonym_graph",
5.          "synonyms": [
6.             "elk, elkb, Elastic Stack"
7.          ]
8.      }
9.    }
10.  ......

要更改现有索引的同义词，我们可以重新创建索引并重新索引所有文档，这是愚蠢且低效的。

更好的方法是更新索引的设置。 但是，我们需要在更新设置之前关闭索引，然后重新打开它才能访问它：

1.  POST /synonym_graph/_close

4.  PUT /synonym_graph/_settings
5.  {
6.    "settings": {
7.      "index.analysis.filter.synonym_filter.synonyms": [
8.        "elk, elkb, Elastic Stack"
9.      ]
10.    }
11.  }

13.  POST /synonym_graph/_open

请注意更新索引设置的特殊语法。

运行上述命令后，我们可以通过如下命令的返回值来进行验证：

GET synonym_graph

上面的命令返回：

`

1.  {
2.    "synonym_graph": {
3.      "aliases": {},
4.      "mappings": {
5.        "properties": {
6.          "name": {
7.            "type": "text",
8.            "analyzer": "index_analyzer",
9.            "search_analyzer": "search_analyzer"
10.          }
11.        }
12.      },
13.      "settings": {
14.        "index": {
15.          "routing": {
16.            "allocation": {
17.              "include": {
18.                "_tier_preference": "data_content"
19.              }
20.            }
21.          },
22.          "number_of_shards": "1",
23.          "provided_name": "synonym_graph",
24.          "creation_date": "1673501061514",
25.          "analysis": {
26.            "filter": {
27.              "synonym_filter": {
28.                "type": "synonym_graph",
29.                "synonyms": [
30.                  "elk, elkb, Elastic Stack"
31.                ]
32.              }
33.            },
34.            "analyzer": {
35.              "index_analyzer": {
36.                "filter": [
37.                  "lowercase"
38.                ],
39.                "tokenizer": "standard"
40.              },
41.              "search_analyzer": {
42.                "filter": [
43.                  "lowercase",
44.                  "synonym_filter"
45.                ],
46.                "tokenizer": "standard"
47.              }
48.            }
49.          },
50.          "number_of_replicas": "1",
51.          "uuid": "UCIWtpQMTsCc1TwnvsywHA",
52.          "version": {
53.            "created": "8060099"
54.          }
55.        }
56.      }
57.    }
58.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

让我们使用 _analyzer 端点测试 search_analyzer 并查看生成的 token：

1.  GET /synonym_graph/_analyze
2.  {
3.    "analyzer": "search_analyzer",
4.    "text": "elk"
5.  }

上述命令返回：

它表明 elk 搜索查询被三个同义词的 token 替换和扩展（由 expand 选项控制）。 它还证明，如果在索引时应用等效同义词，则结果索引的大小可以显着增加。

然后当我们再次执行相同的搜索时：

1.  GET /synonym_graph/_search?filter_path=**.hits
2.  {
3.    "query": {
4.      "match": {
5.        "name": "elk"
6.      }
7.    }
8.  }

这次搜索的结果是：

`

1.  {
2.    "hits": {
3.      "hits": [
4.        {
5.          "_index": "synonym_graph",
6.          "_id": "3",
7.          "_score": 1.6949677,
8.          "_source": {
9.            "name": "Elastic Stack is so widely used"
10.          }
11.        },
12.        {
13.          "_index": "synonym_graph",
14.          "_id": "2",
15.          "_score": 1.1220688,
16.          "_source": {
17.            "name": "elkb is useful"
18.          }
19.        },
20.        {
21.          "_index": "synonym_graph",
22.          "_id": "1",
23.          "_score": 1.0126972,
24.          "_source": {
25.            "name": "elk is very powerful"
26.          }
27.        }
28.      ]
29.    }
30.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

我们可以看到三个文档都被搜索出来了。

使用同义词文件

上面我们一直在创建索引时直接指定同义词列表。 但是，当你有大量同义词时，将它们全部添加到索引中会很麻烦。 更好的方法是将它们存储在一个文件中，然后动态地将它们加载到索引中。 使用同义词文件有很多好处，其中包括：

• 方便维护大量的同义词。
• 可以被不同的索引使用。
• 可以在不关闭索引的情况下动态重新加载。

首先，我们需要先将同义词放入一个文件中。 每行都是一个同义词规则，与上面演示的相同。 更多细节可以在官方文档中找到。

我们将创建的同义词文件称为 synonyms.txt，但可以任意命名。 它具有以下内容：

1.  $ pwd
2.  /Users/liuxg/data/docker8
3.  $ ls
4.  docker-compose.yml synonyms.txt
5.  $ cat synonyms.txt 
6.  # This is a comment! The file is named synonyms.txt.
7.  elk,elkb,Elastic Stack

然后我们需要将同义词文件绑定到 Docker 容器中。 更新 docker-compose.yaml 如下：

docker-compose.yml

`

1.  version: "3.9"
2.  services:
3.    elasticsearch:
4.      image: elasticsearch:8.6.0
5.      environment:
6.        - discovery.type=single-node
7.        - ES_JAVA_OPTS=-Xms1g -Xmx1g
8.        - xpack.security.enabled=false
9.      volumes:
10.        - type: volume
11.          source: es_data
12.          target: /usr/share/elasticsearch/data
13.        - type: bind
14.          source: ./synonyms.txt
15.          target: /usr/share/elasticsearch/config/synonyms.txt      
16.      ports:
17.        - target: 9200
18.          published: 9200
19.      networks:
20.        - elastic

22.    kibana:
23.      image: kibana:8.6.0
24.      ports:
25.        - target: 5601
26.          published: 5601
27.      depends_on:
28.        - elasticsearch
29.      networks:
30.        - elastic      

32.  volumes:
33.    es_data:
34.      driver: local

36.  networks:
37.    elastic:
38.      name: elastic
39.      driver: bridge

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

我们可以使用 CTRL+C 来终止之前运行的 docker，然后再次使用如下命令来启动：

docker-compose up

请注意，同义词文件已加载到容器中的 config 文件夹中。你可以进入容器并使用以下两个命令之一检查它：

1.  # User docker
2.  docker exec -it elasticsearch-1  bash

4.  # User docker-compose
5.  docker-compose exec elasticsearch bash

现在我们需要停止并重新启动服务以使更改生效。 请注意，仅重新启动服务将不起作用。

1.  docker-compose stop elasticsearch
2.  docker-compose up -d elasticsearch

1.  $ docker ps
2.  CONTAINER ID   IMAGE                 COMMAND                  CREATED          STATUS          PORTS                              NAMES
3.  3ae4b728dd44   kibana:8.6.0          "/bin/tini -- /usr/l…"   23 seconds ago   Up 21 seconds   0.0.0.0:5601->5601/tcp             docker8-kibana-1
4.  878c82384761   elasticsearch:8.6.0   "/bin/tini -- /usr/l…"   23 seconds ago   Up 22 seconds   0.0.0.0:9200->9200/tcp, 9300/tcp   docker8-elasticsearch-1
5.  $ docker exec -it docker8-elasticsearch-1 bash
6.  elasticsearch@878c82384761:~$ pwd
7.  /usr/share/elasticsearch
8.  elasticsearch@878c82384761:~$ ls
9.  LICENSE.txt  NOTICE.txt  README.asciidoc  bin  config  data  jdk  lib  logs  modules  plugins
10.  elasticsearch@878c82384761:~$ cd config/
11.  elasticsearch@878c82384761:~/config$ ls
12.  elasticsearch-plugins.example.yml  jvm.options             log4j2.properties  synonyms.txt
13.  elasticsearch.keystore             jvm.options.d           role_mapping.yml   users
14.  elasticsearch.yml                  log4j2.file.properties  roles.yml          users_roles

从上面的输出中，我们可以看到 synonyms.txt 已经被成功地加载到容器里了。

然后我们可以使用同义词文件创建一个新索引：

`

1.  PUT /synonym_graph_file
2.  {
3.    "settings": {
4.      "index": {
5.        "analysis": {
6.          "analyzer": {
7.            "index_analyzer": {
8.              "tokenizer": "standard",
9.              "filter": [
10.                "lowercase"
11.              ]
12.            },
13.            "search_analyzer": {
14.              "tokenizer": "standard",
15.              "filter": [
16.                "lowercase",
17.                "synonym_filter"
18.              ]
19.            }
20.          },
21.          "filter": {
22.            "synonym_filter": {
23.              "type": "synonym_graph",
24.              "synonyms_path": "synonyms.txt",
25.              "updateable": true
26.            }
27.          }
28.        }
29.      }
30.    },
31.    "mappings": {
32.      "properties": {
33.        "name": {
34.          "type": "text",
35.          "analyzer": "index_analyzer",
36.          "search_analyzer": "search_analyzer"
37.        }
38.      }
39.    }
40.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

关键点：

• 对于 synonyms_path，它是同义词文件相对于 Elasticsearch 服务器中 config 文件夹的路径。
• 添加了一个新的 updateable 字段，它指定相应的过滤器是否可更新。 我们很快就会看到如何在不关闭和打开索引的情况下重新加载搜索分析器。

这个新索引 synonym_graph_file 的行为应该与前一个 synonym_graph 的行为相同。

现在让我们在同义词文件中添加更多的同义词，其内容如下：

1.  $ pwd
2.  /Users/liuxg/data/docker8
3.  $ ls
4.  docker-compose.yml synonyms.txt
5.  $ cat synonyms.txt 
6.  # This is a comment! The file is named synonyms.txt.
7.  elk,elkb,Elastic Stack
8.  JS => JavaScript
9.  TS => TypeScript
10.  Py => Python

添加同义词后，我们可以关闭并打开索引使其生效。 然而，由于我们将同义词过滤器标记为可更新，我们可以重新加载搜索分析器以使更改立即生效，而无需关闭索引，因此无需停机。

要重新加载索引的搜索分析器，我们需要调用 _reload_search_analyzers 端点：

POST /synonym_graph_file/_reload_search_analyzers

上面的命令输出为：

`

1.  {
2.    "_shards": {
3.      "total": 2,
4.      "successful": 1,
5.      "failed": 0
6.    },
7.    "reload_details": [
8.      {
9.        "index": "synonym_graph_file",
10.        "reloaded_analyzers": [
11.          "search_analyzer"
12.        ],
13.        "reloaded_node_ids": [
14.          "tZLy82KRTaiCdpsbkEYnuA"
15.        ]
16.      }
17.    ]
18.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

现在，当我们分析 JS 字符串时，我们将看到返回的 javascript token。

1.  GET /synonym_graph_file/_analyze
2.  {
3.    "analyzer": "search_analyzer",
4.    "text": "JS"
5.  }

上面的命令返回：

1.  {
2.    "tokens": [
3.      {
4.        "token": "javascript",
5.        "start_offset": 0,
6.        "end_offset": 2,
7.        "type": "SYNONYM",
8.        "position": 0
9.      }
10.    ]
11.  }

这里应该注意两件重要的事情：

• 如果同义词过滤器的 updateable 设置为true，那么对应的分析器只能作为 search_analyzer 使用，不能用于索引，即使类型是同义词。
• updateable 选项只能在同义词文件与 synonyms_path 选项一起使用时使用，而不是在同义词直接通过 synonyms 选项提供时使用。

恭喜你到达这里！ 我们已经涵盖了在 Elasticsearch 中使用同义词功能的所有要点。

我们已经分别介绍了如何在索引时间和搜索时间分析步骤中使用同义词。 此外，还介绍了如何直接提供同义词列表，以及如何通过文件提供。 最后但同样重要的是，介绍了关于如何更新现有索引的同义词列表的不同方法。 建议重新加载索引的搜索分析器，因为它不会给服务带来停机时间。