歡迎光臨
每天分享高質量文章

全文搜索引擎選 ElasticSearch 還是 Solr?

  • 什麼是全文搜索
  • 為什麼要用全文搜索搜索引擎
  • Lucene,Solr,ElasticSearch ?
  • Elasticsearch vs Solr 的選擇
  • 總結

最近專案組安排了一個任務,專案中用到了基於 Solr 的全文搜索,但是該 Solr 搜索雲專案不穩定,經常查詢不出來資料,需要手動全量同步。

而且它還是其他團隊在維護,依賴性太強,導致 Solr 服務一齣問題,我們的專案也基本癱瘓,因為所有的依賴查詢都無結果資料了。

所以考慮開發一個適配層,如果 Solr 搜索出問題,自動切換到新的搜索 ES。其實可以通過 Solr 集群或者服務容錯等設計來解決該問題。

但是先不考慮本身設計的合理性,領導需要開發,所以我開始踏上了搭建 ES 服務的道路,從零開始,因為之前完全沒接觸過 ES,所以通過本系列來記錄下自己的開發過程。

本篇文章的總體內容大致如下圖:

由 ReyCG 精心繪製並提供

什麼是全文搜索

什麼是全文搜索引擎?百度百科中的定義:

全文搜索引擎是目前廣泛應用的主流搜索引擎。它的工作原理是計算機索引程式通過掃描文章中的每一個詞,對每一個詞建立一個索引,指明該詞在文章中出現的次數和位置,當用戶查詢時,檢索程式就根據事先建立的索引進行查找,並將查找的結果反饋給用戶的檢索方式。這個過程類似於通過字典中的檢索字表查字的過程。

從定義中我們已經可以大致瞭解全文檢索的思路了,為了更詳細的說明,我們先從生活中的資料說起。

我們生活中的資料總體分為兩種:

  • 結構化資料:指具有固定格式或有限長度的資料,如資料庫,元資料等。
  • 非結構化資料:非結構化資料又可稱為全文資料,指不定長或無固定格式的資料,如郵件,Word 文件等。

當然有的地方還會有第三種:半結構化資料,如 XML,HTML 等,當根據需要可按結構化資料來處理,也可抽取出純文本按非結構化資料來處理。

根據兩種資料分類,搜索也相應的分為兩種:結構化資料搜索和非結構化資料搜索。

對於結構化資料,我們一般都是可以通過關係型資料庫(MySQL,Oracle 等)的 table 的方式儲存和搜索,也可以建立索引。

對於非結構化資料,也即對全文資料的搜索主要有兩種方法:

  • 順序掃描
  • 全文檢索

順序掃描:通過文字名稱也可瞭解到它的大概搜索方式,即按照順序掃描的方式查詢特定的關鍵字。

例如給你一張報紙,讓你找到該報紙中“RNG”的文字在哪些地方出現過。你肯定需要從頭到尾把報紙閱讀掃描一遍,然後標記出關鍵字在哪些版塊出現過以及它的出現位置。

這種方式無疑是最耗時的最低效的,如果報紙排版字體小,而且版塊較多甚至有多份報紙,等你掃描完你的眼睛也差不多了。

全文檢索:對非結構化資料順序掃描很慢,我們是否可以進行優化?把我們的非結構化資料想辦法弄得有一定結構不就行了嗎?

將非結構化資料中的一部分信息提取出來,重新組織,使其變得有一定結構,然後對此有一定結構的資料進行搜索,從而達到搜索相對較快的目的。

這種方式就構成了全文檢索的基本思路。這部分從非結構化資料中提取出的然後重新組織的信息,我們稱之索引。

還以讀報紙為例,我們想關註英雄聯盟 S8 全球總決賽的新聞,假如都是 RNG 的粉絲,如何快速找到 RNG 新聞的報紙和版塊呢?

全文檢索的方式就是,將所有報紙中所有版塊中關鍵字進行提取,如”EDG”,”RNG”,”FW”,”戰隊”,”英雄聯盟”等。

然後對這些關鍵字建立索引,通過索引我們就可以對應到該關鍵詞出現的報紙和版塊。註意區別目錄搜索引擎。

為什麼要用全文搜索搜索引擎

之前,有同事問我,為什麼要用搜索引擎?我們的所有資料在資料庫裡面都有,而且 Oracle、SQL Server 等資料庫里也能提供查詢檢索或者聚類分析功能,直接通過資料庫查詢不就可以了嗎?

確實,我們大部分的查詢功能都可以通過資料庫查詢獲得,如果查詢效率低下,還可以通過建資料庫索引,優化 SQL 等方式提升效率,甚至通過引入快取來加快資料的傳回速度。

如果資料量更大,就可以分庫分表來分擔查詢壓力。那為什麼還要全文搜索引擎呢?我們主要從以下幾個原因分析:

資料型別

全文索引搜索支持非結構化資料的搜索,可以更好地快速搜索大量存在的任何單詞或單詞組的非結構化文本。

例如 Google,百度類的網站搜索,它們都是根據網頁中的關鍵字生成索引,我們在搜索的時候輸入關鍵字,它們會將該關鍵字即索引匹配到的所有網頁傳回;還有常見的專案中應用日誌的搜索等等。

對於這些非結構化的資料文本,關係型資料庫搜索不是能很好的支持。

索引的維護

一般傳統資料庫,全文檢索都實現的很雞肋,因為一般也沒人用資料庫存文本欄位。

進行全文檢索需要掃描整個表,如果資料量大的話即使對 SQL 的語法優化,也收效甚微。

建立了索引,但是維護起來也很麻煩,對於 insert 和 update 操作都會重新構建索引。

什麼時候使用全文搜索引擎:

  • 搜索的資料物件是大量的非結構化的文本資料。
  • 檔案記錄量達到數十萬或數百萬個甚至更多。
  • 支持大量基於交互式文本的查詢。
  • 需要非常靈活的全文搜索查詢。
  • 對高度相關的搜索結果有特殊需求,但是沒有可用的關係資料庫可以滿足。
  • 對不同記錄型別、非文本資料操作或安全事務處理的需求相對較少的情況。

Lucene,Solr,ElasticSearch ?

現在主流的搜索引擎大概就是:Lucene,Solr,ElasticSearch。

img

它們的索引建立都是根據倒排索引的方式生成索引,何謂倒排索引?

維基百科:倒排索引(英語:Inverted index),也常被稱為反向索引、置入檔案或反向檔案,是一種索引方法,被用來儲存在全文搜索下某個單詞在一個文件或者一組文件中的儲存位置的映射。它是文件檢索系統中最常用的資料結構。

Lucene

Lucene 是一個 Java 全文搜索引擎,完全用 Java 編寫。Lucene 不是一個完整的應用程式,而是一個代碼庫和 API,可以很容易地用於嚮應用程式添加搜索功能。Lucene 通過簡單的 API 提供強大的功能:

可擴展的高性能索引:

  • 在現代硬體上超過 150GB /小時。
  • 小 RAM 要求,只有 1MB 堆。
  • 增量索引與批量索引一樣快。
  • 索引大小約為索引文本大小的 20-30%。

強大,準確,高效的搜索演算法:

  • 排名搜索:首先傳回最佳結果。
  • 許多強大的查詢型別:短語查詢,通配符查詢,鄰近查詢,範圍查詢等。
  • 現場搜索(例如標題,作者,內容)。
  • 按任何欄位排序。
  • 使用合併結果進行多索引搜索。
  • 允許同時更新和搜索。
  • 靈活的分面,突出顯示,連接和結果分組。
  • 快速,記憶體效率和錯誤容忍的建議。
  • 可插拔排名模型,包括矢量空間模型和 Okapi BM25。
  • 可配置儲存引擎(編解碼器)。

跨平臺解決方案:

  • 作為 Apache 許可下的開源軟體提供 ,允許您在商業和開源程式中使用 Lucene。
  • 100%-pure Java。
  • 可用的其他編程語言中的實現是索引兼容的。

Apache 軟體基金會:

  • 獲得 Apache 軟體基金會提供的開源軟體專案的 Apache 社區的支持。
  • 但是 Lucene 只是一個框架,要充分利用它的功能,需要使用 Java,並且在程式中集成 Lucene。
  • 需要很多的學習瞭解,才能明白它是如何運行的,熟練運用 Lucene 確實非常複雜。

Solr

Apache Solr 是一個基於名為 Lucene 的 Java 庫構建的開源搜索平臺。它以用戶友好的方式提供 Apache Lucene 的搜索功能。

作為一個行業參與者已近十年,它是一個成熟的產品,擁有強大而廣泛的用戶社區。

它提供分佈式索引,複製,負載平衡查詢以及自動故障轉移和恢復。如果它被正確部署然後管理得好,它就能夠成為一個高度可靠,可擴展且容錯的搜索引擎。

很多互聯網巨頭,如 Netflix,eBay,Instagram 和亞馬遜(CloudSearch)都使用 Solr,因為它能夠索引和搜索多個站點。

主要功能串列包括:

  • 全文搜索
  • 突出
  • 分面搜索
  • 實時索引
  • 動態群集
  • 資料庫集成
  • NoSQL 功能和豐富的文件處理(例如 Word 和 PDF 檔案)

ElasticSearch

Elasticsearch 是一個開源(Apache 2 許可證),基於 Apache Lucene 庫構建的 RESTful 搜索引擎。

Elasticsearch 是在 Solr 之後幾年推出的。它提供了一個分佈式,多租戶能力的全文搜索引擎,具有 HTTP Web 界面(REST)和無架構 JSON 文件。

Elasticsearch 的官方客戶端庫提供 Java,Groovy,PHP,Ruby,Perl,Python,.NET 和 Javascript。

分佈式搜索引擎包括可以劃分為分片的索引,並且每個分片可以具有多個副本。

每個 Elasticsearch 節點都可以有一個或多個分片,其引擎也可以充當協調器,將操作委派給正確的分片。

Elasticsearch 可通過近實時搜索進行擴展。其主要功能之一是多租戶。主要功能串列包括:

  • 分佈式搜索
  • 多租戶
  • 分析搜索
  • 分組和聚合

Elasticsearch vs Solr 的選擇

由於 Lucene 的複雜性,一般很少會考慮它作為搜索的第一選擇,排除一些公司需要自研搜索框架,底層需要依賴 Lucene。

所以這裡我們重點分析哪一個更好?它們有什麼不同?你應該使用哪一個?

img

歷史比較

Apache Solr 是一個成熟的專案,擁有龐大而活躍的開發和用戶社區,以及 Apache 品牌。

Solr 於 2006 年首次發佈到開源,長期以來一直占據著搜索引擎領域,並且是任何需要搜索功能的人的首選引擎。

它的成熟轉化為豐富的功能,而不僅僅是簡單的文本索引和搜索; 如分面,分組,強大的過濾,可插入的文件處理,可插入的搜索鏈組件,語言檢測等。

Solr 在搜索領域占據了多年的主導地位。然後,在 2010 年左右,Elasticsearch 成為市場上的另一種選擇。

那時候,它遠沒有 Solr 那麼穩定,沒有 Solr 的功能深度,沒有思想分享,品牌等等。

Elasticsearch 雖然很年輕,但它也自己的一些優勢,Elasticsearch 建立在更現代的原則上,針對更現代的用例,並且是為了更容易處理大型索引和高查詢率而構建的。

此外,由於它太年輕,沒有社區可以合作,它可以自由地向前推進,而不需要與其他人(用戶或開發人員)達成任何共識或合作,向後兼容,或任何其他更成熟的軟體通常必須處理。

因此,它在 Solr 之前就公開了一些非常受歡迎的功能(例如,接近實時搜索,英文:Near Real-Time Search)。

從技術上講,NRT 搜索的能力確實來自 Lucene,它是 Solr 和 Elasticsearch 使用的基礎搜索庫。

具有諷刺意味的是,因為 Elasticsearch 首先公開了 NRT 搜索,所以人們將 NRT 搜索與 Elasticsearch 聯繫在一起。

儘管 Solr 和 Lucene 都是同一個 Apache 專案的一部分,但是,人們會首先期望 Solr 具有如此高要求的功能。

特征差異比較

這兩個搜索引擎都是流行的,先進的的開源搜索引擎。它們都是圍繞核心底層搜索庫 Lucene 構建的,但它們又是不同的。

像所有東西一樣,每個都有其優點和缺點,根據您的需求和期望,每個都可能更好或更差。

Solr 和 Elasticsearch 都在快速發展,所以,話不多說,先來看下它們的差異清單:

img

瞭解更多:http://solr-vs-elasticsearch.com/

綜合比較

另外,我們再從以下幾個方面來分析下:

①近幾年的流行趨勢

我們查看一下這兩種產品的 Google 搜索趨勢。谷歌趨勢表明,與 Solr 相比,Elasticsearch 具有很大的吸引力,但這並不意味著 Apache Solr 已經死亡。

雖然有些人可能不這麼認為,但 Solr 仍然是最受歡迎的搜索引擎之一,擁有強大的社區和開源支持。

img

②安裝和配置

與 Solr 相比,Elasticsearch 易於安裝且非常輕巧。此外,您可以在幾分鐘內安裝並運行 Elasticsearch。

但是,如果 Elasticsearch 管理不當,這種易於部署和使用可能會成為一個問題。

基於 JSON 的配置很簡單,但如果要為檔案中的每個配置指定註釋,那麼它不適合您。

總的來說,如果您的應用使用的是 JSON,那麼 Elasticsearch 是一個更好的選擇。

否則,請使用 Solr,因為它的 schema.xml 和 solrconfig.xml 都有很好的文件記錄。

③社區

Solr 擁有更大,更成熟的用戶,開發者和貢獻者社區。ES 雖擁有的規模較小但活躍的用戶社區以及不斷增長的貢獻者社區。

Solr 是真正的開源社區代表。任何人都可以為 Solr 做出貢獻,並且根據優點選出新的 Solr 開發人員(也稱為提交者)。

Elasticsearch 在技術上是開源的,但在精神上卻不那麼重要。任何人都可以看到來源,任何人都可以更改它並提供貢獻,但只有 Elasticsearch 的員工才能真正對 Elasticsearch 進行更改。

Solr 貢獻者和提交者來自許多不同的組織,而 Elasticsearch 提交者來自單個公司。

④成熟度

Solr 更成熟,但 ES 增長迅速,我認為它穩定。

⑤文件

Solr 在這裡得分很高。它是一個非常有據可查的產品,具有清晰的示例和 API 用例場景。

Elasticsearch 的文件組織良好,但它缺乏好的示例和清晰的配置說明。

總結

那麼,到底是選擇 Solr 還是 Elasticsearch?有時很難找到明確的答案。無論您選擇 Solr 還是 Elasticsearch,首先需要瞭解正確的用例和未來需求,總結它們的每個屬性。

記住下麵這些要點:

  • 由於易於使用,Elasticsearch 在新開發者中更受歡迎。但是,如果您已經習慣了與 Solr 合作,請繼續使用它,因為遷移到 Elasticsearch 沒有特定的優勢。
  • 如果除了搜索文本之外還需要它來處理分析查詢,Elasticsearch 是更好的選擇。
  • 如果需要分佈式索引,則需要選擇 Elasticsearch。對於需要良好可伸縮性和性能的雲和分佈式環境,Elasticsearch 是更好的選擇。
  • 兩者都有良好的商業支持(咨詢,生產支持,整合等)。
  • 兩者都有很好的操作工具,儘管 Elasticsearch 因其易於使用的 API 而更多地吸引了 DevOps 人群,因此可以圍繞它創建一個更加生動的工具生態系統。
  • Elasticsearch 在開源日誌管理用例中占據主導地位,許多組織在 Elasticsearch 中索引它們的日誌以使其可搜索。雖然 Solr 現在也可以用於此目的,但它只是錯過了這一想法。
  • Solr 仍然更加面向文本搜索。另一方面,Elasticsearch 通常用於過濾和分組,分析查詢工作負載,而不一定是文本搜索。
  • Elasticsearch 開發人員在 Lucene 和 Elasticsearch 級別上投入了大量精力使此類查詢更高效(降低記憶體占用和 CPU 使用)。
  • 因此,對於不僅需要進行文本搜索,而且需要複雜的搜索時間聚合的應用程式,Elasticsearch 是一個更好的選擇。
  • Elasticsearch 更容易上手,一個下載和一個命令就可以啟動一切。Solr 傳統上需要更多的工作和知識,但 Solr 最近在消除這一點上取得了巨大的進步,現在只需努力改變它的聲譽。
  • 在性能方面,它們大致相同。我說“大致”,因為沒有人做過全面和無偏見的基準測試。對於 95% 的用例,任何一種選擇在性能方面都會很好,剩下的 5% 需要用它們的特定資料和特定的訪問樣式來測試這兩種解決方案。
  • 從操作上講,Elasticsearch 使用起來比較簡單,它只有一個行程。Solr 在其類似 Elasticsearch 的完全分佈式部署樣式 SolrCloud 中依賴於 Apache ZooKeeper,ZooKeeper 是超級成熟,超級廣泛使用等等,但它仍然是另一個活躍的部分。
  • 也就是說,如果您使用的是 Hadoop,HBase,Spark,Kafka 或其他一些較新的分佈式軟體,您可能已經在組織的某個地方運行 ZooKeeper。
  • 雖然 Elasticsearch 內置了類似 ZooKeeper 的組件 Xen,但 ZooKeeper 可以更好地防止有時在 Elasticsearch 集群中出現的可怕的裂腦問題。
  • 公平地說,Elasticsearch 開發人員已經意識到這個問題,並致力於改進 Elasticsearch 的這個方面。
  • 如果您喜歡監控和指標,那麼使用 Elasticsearch,您將會進入天堂。這個東西比新年前夜在時代廣場可以擠壓的人有更多的指標!Solr 暴露了關鍵指標,但遠不及 Elasticsearch 那麼多。

總之,兩者都是功能豐富的搜索引擎,只要設計和實現得當,它們或多或少都能提供相同的性能。

赞(0)

分享創造快樂