两分钟告诉你：Solr与Elasticsearch的匹配功能控制的区别

Posted 2021-04-21 小象

译者：孙薇

原文链接：https://dzone.com/articles/solr-vs-elasticsearch-for-controlling-matching

小象科技原创作品，欢迎大家疯狂转发；

机构、自媒体平台转载务必至后台留言，申请版权。

对比：Solr与Elasticsearch的匹配功能控制

网上关于Solr与Elasticsearch的对比文章一抓一大把，但很少见到在传统——常规在线检索结果控制方面的对比文。

笔者在工作时投入了大量时间，来提高Solr与Elasticsearch的搜索结果相关性（关于这个主题笔者著有书籍）。在这组系列文的开篇章中，笔者想要从细节入手，帮助大家了解该在传统搜索问题上使用哪种技术。关键在于，要根据自己的需求来优化结果的相关性。坦率来讲，就算你认为没什么必要，这种做法也是必须的。所有人都冲着搜索栏而去，那么你的搜索能否“给出”他们想要的东西呢，还是仅仅返回一组随机的10个结果？

总之，对比Solr和Elasticsearch的搜索相关性可以按三个标准来执行：

1、控制匹配的可能——什么样的结果算是匹配/不匹配搜索？

2、 控制排列的可能——在匹配出的结果组中，哪些结果最为相关？

3、创建插件的可能——在结果匹配/排序时，在API之上用户还有多大的可操作性？

在本文中，笔者将会从第一点谈起：通过对比，分析如何使用这些搜索引擎操纵匹配行为。

1

相似之处

大于差异

在深入讨论之前，我们需要注意这一点：在很多方面Solr和Elasticsearch相似之处多过差异。从基础水平上，两者均为使用者提供了大量操纵搜索相关性的可能。同为基于Lucene的开源搜索引擎，它们与黑盒测试通过的商用软件有很大的不同。商用软件限制了用户自行优化的可能性，而开源软件却广泛支持各类用例，从基于文档的传统搜索，到地理感知（geo-aware）、图谱搜索（graph search），还有其他你能想到的。两者均提供丰富的查询DSL和文本分析DSL，允许使用者严格控制匹配与排列过程。正因如此，在《Relevant Search》中几乎都能找到实用案例。

也就是说，尽管核心功能相同，但通过人机工程学和API，可以决定你的搜索方案简单还是复杂。

下面我们将深入对比，分析两者区别：一个在控制匹配时相对直接，另一个需要更多思考和工程来辅助。

2

对比Solr与

Elasticsearch的

匹配功能控制

匹配控制可以归结为：如何从细节上优化将文本转换为个体标记（individual token）的方式。搜索引擎以标记作为基础单位，在进行“匹配”时必须准确比对标记。将搜索获得的标记与文档中的标记进行比对的过程需要标准化。例如，搜索全大写的“CAT”时，在未经合适文本操纵的情况下，全小写的“cat”是不匹配的。再举个更初级的例子：确定是否该将“小猫咪（kitty）”作为“猫（cat）”的同义词。搜索“kitty”的结果应当跟搜索“cat”的结果一致吗？考虑到英语单词有多种形式（run、running和ran），标准化过程对准确定义何时该匹配、何时不匹配非常重要。

标准化任务通过“分析”功能来进行（我们曾讨论过）。分析功能控制着将从文档/搜索中所获得的文本转化为标记的过程。搜索是否相关常可总结为控制搜索过程，仔细区分匹配与不匹配的技巧。 Solr与Elasticsearch都支持Lucene分析器的底层库，创建分析器的人机工程学只有表面上的区别。

Solr（直到最近）鼓励用户用XML配置文件（schema.xml）来控制这一过程，而Elasticsearch则提供了RESTful JSON API来完成相同的工作。 两者在构建分析器时所提供的组成部分相同。通过一些字符过滤器操纵原本的字符流，用tokenizer将字符流拆成标记，最后用可配置的序列标记过滤器整理、拼接、删除、生成或者操纵这些标记。

为了严格控制这一过程，除了要分析搜索引擎中的内容之外，两者均要求指定单独的查询分析器。搜索分析器会将搜索字符串转化为标记，控制如何与索引文本所生成标记的相匹配。这非常伟大。试想案例：如果想要拓展原始的搜索查询，在其中涵盖额外同义词的话。

然而，Solr的查询搜索有两个严重的漏洞，最为头疼的问题就是所谓的“sea biscuit问题”，简单来说就是Solr的默认查询分析程序在将内容传递给查询期分析器（query time analyzer）之前，使用空格分隔文本。因此，如果定义“sea biscuit”是“seabiscuit”的同义词，这条规则不会生效。

原因在于：分隔查询词的每个空格在分析时有独特定义，与查询字符串中的剩余文本不同。查询期分析器将“sea”作为单独的一个词，而同义词过滤器无法发现它后面的“biscuit”。还不只是同义词的问题，需要同时操纵多个标记的过程也会受到影响。在尝试控制匹配过程时，可能会有很大限制与意外。排列sad trombone。

这个问题不断引发意外、相关性bug还有用户组讨论。甚至比较熟练的Solr使用者也会遇到这类意外。并不是完全无法解决，已经出现了很多Solrplugins来解决这个问题。Solr还赋予用户很大权力，可以编写任何插件，更有效地解决这个问题。

但并不是所有人都想用其他插件，或者编写Java程序来解决这个问题。Solr的另一个问题是：它只允许用户在字段的配置中控制查询端分析器，而Elasticsearch允许用户在任意级别中控制分析器，包括在运行查询时发送可用的分析器。Elasticsearch选择更为广泛。

而且非常方便。举个例子，有时用户想通过同义词来查询字段，有时想用其他方式。使用Elasticsearch可以用不同的方式简单查询同一个字段，只需在查询时发送分析器自变量即可。有时候在同义词分析器中发送，有时可以用默认的。而用Solr需要将内容复制到另一个字段，来选择不同的查询分析器。

结论：Elasticsearch在匹配时明显更好一些。在操作匹配时，Elasticsearch出现的意外最少，提供的可配置自由度最高，无需编写插件就能完全很多工作。

下一次，我们会讨论Solr跟Elasticsearch如何与查询API相匹配的问题。Elasticsearch是否还会胜出呢？在系列讨论中，我们还会比较每个搜索引擎的可插拔性，优胜者又会是谁呢？

更多精彩内容，请点击"阅读原文"