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

Question

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

他们告诉我，一种颜色可能具有数百个同义词（白色：象牙，奶油，腻子等），我们应该在我们的操作数据库中进行映射。我不相信。如果我们在查询时有一百个白色的同义词列表，会真的对性能产生巨大的影响吗？如果那很慢，那么在对文档建立索引时进行同义词映射是否可以解决问题？

顾问希望我们进行反向映射，将标准颜色分配给主数据库中的项目，然后将其传递给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"
            }
        }

但是，根据要运行的查询以及与查询时间匹配的条件，可以定义an index_analyzer和a search_analyzer，使用收缩或扩展，因此，对于“正确”的解决方案，不仅要考虑什么，还需要考虑更多的变量。你提到过 在上面的方法中，我基本上在索引时使所有“ white”的同义词相等。但是，鉴于要运行的查询，也许您不需要这样做。

结论：

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