全文搜索引擎是目前普遍應用的主流搜索引擎。它的工做原理是計算機索引程序經過掃描文章中的每個詞,對每個詞創建一個索引,指明該詞在文章中出現的次數和位置,當用戶查詢時,檢索程序就根據事先創建的索引進行查找,並將查找的結果反饋給用戶的檢索方式。這個過程相似於經過字典中的檢索字表查字的過程。html
從定義中咱們已經能夠大體瞭解全文檢索的思路了,爲了更詳細的說明,咱們先從生活中的數聽說起。java
咱們生活中的數據整體分爲兩種:結構化數據 和 非結構化數據。mysql
結構化數據: 指具備固定格式或有限長度的數據,如數據庫,元數據等。git
非結構化數據: 非結構化數據又可稱爲全文數據,指不定長或無固定格式的數據,如郵件,word文檔等。算法
半結構化數據,如XML,HTML等,當根據須要可按結構化數據來處理,也可抽取出純文本按非結構化數據來處理。spring
根據兩種數據分類,搜索也相應的分爲兩種:結構化數據搜索和非結構化數據搜索。sql
對於結構化數據,咱們通常都是能夠經過關係型數據庫(mysql,oracle等)的 table 的方式存儲和搜索,也能夠創建索引。 對於非結構化數據,也即對全文數據的搜索主要有兩種方法:順序掃描法,全文檢索。數據庫
順序掃描:經過文字名稱也可瞭解到它的大概搜索方式,即按照順序掃描的方式查詢特定的關鍵字。 例如給你一張報紙,讓你找到該報紙中「RNG」的文字在哪些地方出現過。你確定須要從頭至尾把報紙閱讀掃描一遍而後標記出關鍵字在哪些版塊出現過以及它的出現位置。編程
這種方式無疑是最耗時的最低效的,若是報紙排版字體小,並且版塊較多甚至有多份報紙,等你掃描完你的眼睛也差很少了。api
全文搜索:對非結構化數據順序掃描很慢,咱們是否能夠進行優化?把咱們的非結構化數據想辦法弄得有必定結構不就好了嗎?將非結構化數據中的一部分信息提取出來,從新組織,使其變得有必定結構,而後對此有必定結構的數據進行搜索,從而達到搜索相對較快的目的。這種方式就構成了全文檢索的基本思路。這部分從非結構化數據中提取出的而後從新組織的信息,咱們稱之索引。
還以讀報紙爲例,咱們想關注最近英雄聯盟S8全球總決賽的新聞,假如都是 RNG 的粉絲,如何快速找到 RNG 新聞的報紙和版塊呢?全文搜索的方式就是,將全部報紙中全部版塊中關鍵字進行提取,如"EDG","RNG","FW","戰隊","英雄聯盟"等。而後對這些關鍵字創建索引,經過索引咱們就能夠對應到該關鍵詞出現的報紙和版塊。注意區別目錄搜索引擎。
爲何要用搜索引擎?咱們的全部數據在數據庫裏面都有,並且 Oracle、SQL Server 等數據庫裏也能提供查詢檢索或者聚類分析功能,直接經過數據庫查詢不就能夠了嗎?確實,咱們大部分的查詢功能均可以經過數據庫查詢得到,若是查詢效率低下,還能夠經過建數據庫索引,優化SQL等方式進行提高效率,甚至經過引入緩存來加快數據的返回速度。若是數據量更大,就能夠分庫分表來分擔查詢壓力。
那爲何還要全文搜索引擎呢?咱們主要從如下幾個緣由分析:
數據類型 全文索引搜索支持非結構化數據的搜索,能夠更好地快速搜索大量存在的任何單詞或單詞組的非結構化文本。 例如 Google,百度類的網站搜索,它們都是根據網頁中的關鍵字生成索引,咱們在搜索的時候輸入關鍵字,它們會將該關鍵字即索引匹配到的全部網頁返回;還有常見的項目中應用日誌的搜索等等。對於這些非結構化的數據文本,關係型數據庫搜索不是能很好的支持。
索引的維護 通常傳統數據庫,全文檢索都實現的很雞肋,由於通常也沒人用數據庫存文本字段。進行全文檢索須要掃描整個表,若是數據量大的話即便對SQL的語法優化,也收效甚微。創建了索引,可是維護起來也很麻煩,對於 insert 和 update 操做都會從新構建索引。
何時使用全文搜索引擎:
搜索的數據對象是大量的非結構化的文本數據。
文件記錄量達到數十萬或數百萬個甚至更多。
支持大量基於交互式文本的查詢。
需求很是靈活的全文搜索查詢。
對高度相關的搜索結果的有特殊需求,可是沒有可用的關係數據庫能夠知足。
對不一樣記錄類型、非文本數據操做或安全事務處理的需求相對較少的狀況。
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確實很是複雜。
Apache Solr是一個基於名爲Lucene的Java庫構建的開源搜索平臺。它以用戶友好的方式提供Apache Lucene的搜索功能。做爲一個行業參與者近十年,它是一個成熟的產品,擁有強大而普遍的用戶社區。它提供分佈式索引,複製,負載平衡查詢以及自動故障轉移和恢復。若是它被正確部署而後管理得好,它就可以成爲一個高度可靠,可擴展且容錯的搜索引擎。不少互聯網巨頭,如Netflix,eBay,Instagram和亞馬遜(CloudSearch)都使用Solr,由於它可以索引和搜索多個站點。
主要功能列表包括:
全文搜索
突出
分面搜索
實時索引
動態羣集
數據庫集成
NoSQL功能和豐富的文檔處理(例如Word和PDF文件)
Elasticsearch是一個開源(Apache 2許可證),是一個基於Apache Lucene庫構建的RESTful搜索引擎。
Elasticsearch是在Solr以後幾年推出的。它提供了一個分佈式,多租戶能力的全文搜索引擎,具備HTTP Web界面(REST)和無架構JSON文檔。Elasticsearch的官方客戶端庫提供Java,Groovy,PHP,Ruby,Perl,Python,.NET和Javascript。
分佈式搜索引擎包括能夠劃分爲分片的索引,而且每一個分片能夠具備多個副本。每一個Elasticsearch節點均可以有一個或多個分片,其引擎也能夠充當協調器,將操做委派給正確的分片。
Elasticsearch可經過近實時搜索進行擴展。其主要功能之一是多租戶。
主要功能列表包括:
分佈式搜索
多租戶
分析搜索
分組和聚合
因爲Lucene的複雜性,通常不多會考慮它做爲搜索的第一選擇,排除一些公司須要自研搜索框架,底層須要依賴Lucene。因此這裏咱們重點分析 Elasticsearch 和 Solr。
Elasticsearch vs. Solr。哪個更好?他們有什麼不一樣?你應該使用哪個?
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 具備如此高要求的功能。
特徵 | Solr/SolrCloud | Elasticsearch |
---|---|---|
社區和開發者 | Apache 軟件基金和社區支持 | 單一商業實體及其員工 |
節點發現 | Apache Zookeeper,在大量項目中成熟且通過實戰測試 | Zen內置於Elasticsearch自己,須要專用的主節點才能進行分裂腦保護 |
碎片放置 | 本質上是靜態,須要手動工做來遷移分片,從Solr 7開始 - Autoscaling API容許一些動態操做 | 動態,能夠根據羣集狀態按需移動分片 |
高速緩存 | 全局,每一個段更改無效 | 每段,更適合動態更改數據 |
分析引擎性能 | 很是適合精確計算的靜態數據 | 結果的準確性取決於數據放置 |
全文搜索功能 | 基於Lucene的語言分析,多建議,拼寫檢查,豐富的高亮顯示支持 | 基於Lucene的語言分析,單一建議API實現,高亮顯示從新計算 |
DevOps支持 | 還沒有徹底,但即將到來 | 很是好的API |
非平面數據處理 | 嵌套文檔和父-子支持 | 嵌套和對象類型的天然支持容許幾乎無限的嵌套和父-子支持 |
查詢DSL | JSON(有限),XML(有限)或URL參數 | JSON |
索引/收集領導控制 | 領導者安置控制和領導者從新平衡甚至能夠節點上的負載 | 不可能 |
機器學習 | 內置 - 在流聚合之上,專一於邏輯迴歸和學習排名貢獻模塊 | 商業功能,專一於異常和異常值以及時間序列數據 |
結論:
基礎項目的實際狀況,solr 和 Elasticsearch都能知足功能性需求,但從整個框架對DEVOPs追求和將來可擴展性來計,Elasticsearch更符合框架和業務需求。
一、Elasticsearch中文指南
https://es.xiaoleilu.com/index.html
二、Elasticsearch學習demo
https://gitee.com/quanke/elasticsearch-java-study/tree/master/src/test/java/name/quanke/es/study
三、solr集成spring boot demo
https://gitee.com/11230595/springboot-solr
四、Elasticsearch集成 spring boot demo
https://gitee.com/11230595/springboot-elasticsearch
五、框架對比博客