弹性搜索的最佳同义词方法是什么?

Question

我正在使用弹性搜索实现产品目录中颜色的同义词查询，我一直在要求一些顾问使用ES同义词功能实现它。

他们告诉我，一种颜色可能有数百个同义词(白色:象牙色、奶油色、腻子色等)，我们应该在我们的操作数据库中进行映射。我不相信。如果我们在查询时有一个包含100个white同义词的列表，真的会对性能造成巨大影响吗?如果这样做很慢，那么在索引文档时执行同义词映射是否可以避免这个问题?

顾问希望我们反向进行映射，为主数据库中的项目分配标准颜色，然后将其传递给ES。我不想让他们学习任何关于我们的架构/基础设施的东西，而只是让他们在ES中摆弄他们已经知道如何做的旋钮。

我天真地认为我们可以这样进行吗?用标准颜色装饰或操作数据库真的是正确的方法吗?

Answer 1

我的方法是定义一个同义词文件，如这里的文档所述，并维护该文件。

使用这个，我将创建我的自定义令牌过滤器并在索引时使用它们。如果在查询时执行此操作，可能不会对性能造成很大影响，但最好在索引时执行。查询时的响应时间会更好。

关于你的数据库，我不知道你的架构，我不知道为什么他们说你需要把同义词放在那里。正如您在上面提供的链接中看到的，您可以定义一个简单的文本文件，在其中放入如下内容:

ivory, creme, putty => white
...

这意味着对于索引时发现的任何ivory, creme, putty, ES实际上会索引white，就是这样。

分析器看起来像这样:

       "analyzer" : {
            "synonym" : {
                "tokenizer" : "whitespace",
                "filter" : ["synonym"]
            }
        },
        "filter" : {
            "synonym" : {
                "type" : "synonym",
                "synonyms_path" : "analysis/synonym.txt"
            }
        }

但是根据您想要运行的查询和您需要匹配查询时间的内容，您可以定义index_analyzer和search_analyzer，使用收缩或扩展，因此，对于"右"解决方案，需要查看更多变量，而不仅仅是您提到的。在上面的方法中，我基本上在索引时使"white"的所有同义词相等。但是，考虑到你想要运行的查询，也许你不需要这个。

在结论:

• 我不明白为什么颜色需要保存在数据库中，它们可以很好地在文本文件中指定，正如你上面看到的。也许我没有你用例的所有细节。
最终的解决方案可能涉及分析来自查询本身的输入文本或在索引时分析文本，或两者兼而有之。这一切都取决于你的具体用例和你的查询。
• 在真实数据和真实体积上测试各种解决方案，并比较您获得的性能。
• 通常，同义词方法是在索引时，但不一定是，这取决于用例。