譯者：孫薇；
原文鏈接：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出現的意外最少，提供的可配置自由度最高，無需編寫插件就能完全很多工作。