本篇內容主要講解“Solr與ElasticSearch有哪些異同點”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Solr與ElasticSearch有哪些異同點”吧!

創新互聯建站主營阿圖什網站建設的網絡公司,主營網站建設方案,成都app開發,阿圖什h5小程序開發搭建,阿圖什網站營銷推廣歡迎阿圖什等地區企業咨詢

相同點

• 兩者都基于Lucene實現

這看起來像一句廢話，因為知道這兩個產品的人，一定知道Solr和ElasticSearch都是基于Luence實現的。但其實這句話蘊含了兩層意思。

第一層是Luence支持的功能他們都支持，只是概念和用法上稍有不同。Luence這個引擎已經非常強大，我們在使用搜索引擎時看到的絕大部分功能，Luence都可以實現。比如索引時的分詞，查詢時的切面(Facet)，高亮，拼寫檢查，搜索建議，相似頁面等等，其實這些都是Luence中實現的功能，Solr和ElasticSearch都只不過做了包裝而已。Luence中不僅有倒排索引，還有TermVector這種每個文檔的正排索引，還有DocValue這種列存結構，不同的數據類型支持了不同的搜索要求。舉例來說，對于按某一個列排序的需求，如果只有倒排索引，拿到每個doc的ID之后再去分別做seek取出列值來做排序，DocValue這種按列存的結構可以很快地取出對應document的列值，而減少磁盤seek操作。同樣，在TermVector中記錄了一個doc中每個term的位置，這是實現關鍵詞高亮的基礎。

這句話第二層意思是Luence做不到的事情，Solr和ElasticSearch必須自己想辦法實現。比如Luence是不支持Document的部分更新的。做為一個數據庫+搜索引擎的混合體，Solr和ElasticSearch如果也不支持Document的部分更新肯定說不過去，所以他們兩者都實現了先把原來的文檔讀出來再寫的邏輯。當然，要讀出原來的文檔就要求文檔的原始數據都在，因此Solr中的部分更新要求schema中所有字段要么是stored，要么有docvalue。而ElasticSearch中則比較激進，每個Document默認都會帶_source字段，原始文檔都會存在里面，不用任何配置就可以支持部分更新。另外一個Luence做不了的事情就是文檔的立即可見性。Luence的Document一定要commit刷成Segment后，才能被搜索到。對于一個搜索引擎來講，這無可厚非，寫入的數據過段時間才能被查到非常正常。但是很多人是把Solr和ElasticSearch當數據庫用的，如果寫入的數據不能立刻可見，這對一個數據庫來說是不可以接受的。所以Solr和ElasticSearch都實現了一個“Realtime Get”功能，即寫入的數據，如果是用id去查，是立馬可以查出來的。實現原理也很簡單，Solr/ES里在index前都會先寫log，面對Get請求時，Luence中不可見的數據，可以查log。另外一個有意思的例子是翻頁。在Luence3.5之前是沒有SearchAfter這個接口的，要實現翻頁，Solr的早期版本只能全查出來，然后跳過offset條數據。可想而知，如果用戶深翻，性能有多差。而當Luence開始支持SearchAfter，支持從某一個文檔開始搜索，Solr也開始支持Cursor功能，給上次翻頁的最后一個文檔做個標記，下一頁從這個文檔開始查，大大優化了翻頁功能。

• 不止于搜索

除了單純基于Luence提供的搜索功能，Solr和ElasticSearch還提供了豐富的能力。比如說ElasticSearch的Aggregation能力。ElasticSearch一定是對他的Aggregation功能非常的自信，因為在官方文檔中，Aggregation是介紹完基本概念，安裝部署后的第一章。用戶完全可以把ElasticSearch當成一個分析引擎來用，各種avg，sum，count以及各種聚合方式，都可以實現。Solr也同樣提供了Analytics Component。兩者的分析功能我都沒有使用過，因此我沒有發言權說誰的功能更加強大。ElasticSearch還提供了一個強大的scripting，可以用ES支持的幾種腳本語言來寫一些復雜的求值函數。Solr中也有streamExpression，自定義了豐富的語法和函數讓用戶直接寫表達式來查詢。當然，人見人愛的SQL功能也必不可少，Solr和ElasticSearch均支持SQL和JDBC訪問。兩者支持的SQL功能可能存在一些差異，在這里我沒有細究。

• 分布式架構和高可用

Solr(Cloud)和ElasticSearch都是分布式架構，支持對索引進行分片，將索引分布到不同服務器上來實現scale out。同時，他們都支持給每個Shard來設置多個replica來實現高可用。Shard的多個replica都是主從架構，相當于一寫多讀。主從之間都是同步復制。因此在寫入時，一定需要找到主replica，而讀的時候，隨機選擇replica都能讀到最新數據。同時，Solr和ElasticSearch還支持集群間復制，但兩者的實現稍微有些不同，Solr的集群間復制采用推的方式，而ElasticSearch采用的是拉。Solr支持雙向復制，從而能夠實現雙活，而ElasticSearch只能實現主向從的復制來做主備。此外，一些數據庫常用的運維功能，如snapshot，backup&restore，兩者都支持。

不同點

• 分布式的設計理念不同

Solr在最開始的時候是單機版的，并不是分布式架構。當SolrCloud出現時，才有了分布式架構。Solr選用了Zookeeper來做分布式架構下的協調者。Solr中每一個節點都是對等的，Zookeeper的使用主要是用來存分片的路由信息，以及各個replica之間，overseer節點的搶主。Solr中唯一一個不同的角色就是overseer，相當于Solr集群中的master角色，所有的Collection creation等admin操作，都需要進過overseer節點。同時，overseer節點可以根據AutoScalling框架的配置，在節點丟失和新節點加入時，做一些預設的操作。比如節點丟失時，為該節點上的replica自動再add一個新的replica，保持可用replica數為固定值。AutoScalling框架是Solr 7.0才加入的，從這里開始，Solr才有真正意義上的自動運維，在這之前，Solr的自動運維能力比較弱，就連balance集群，都需要手工去操作。

ElasticSearch從一出生就是分布式架構設計。與Solr不同的是，ElasticSearch并沒有依賴其他產品來做分布式，而是自研了一套Zen Discovery協議來做分布式協調。因此，ElasticSearch不像Solr(Cloud)那樣依賴一套Zookeeper集群。Zen Discovery把節點發現，選主，廣播等事情全都干完了。相對于Solr，ElasticSearch的角色更加豐富，除了有與Solr overseer節點類似的master節點，還可以配置只負責index寫入過程中處理復雜ingest pipeline（比如分詞，變換等等）的ingest node，以及不存數據，只負責Coordination（接受用戶請求，發送到對應replica，然后聚合返回客戶端）的node。當然，Solr也可以通過AutoScalling配置某個節點不放任何replica來達到Coordination node的效果，不過這個配置就復雜的多了。ElasticSearch自動運維能力比較強，通過簡單配置，就可以實現集群的自動balance等運維操作。當節點宕機時，master node也會提升從replica為主，并增加一個replica來保持replica可用數。這些都是ElasticSearch的默認行為，而在Solr中，則需要自己去定義AutoScalling的框架，來配置這些行為。

• Solr能夠深度定制而ElasticSearch更重于開箱即用

最近我solr和ElasticSearch的兩個客戶端都使用過，給我的感覺是ElasticSearch更加簡單易用。有很多的功能ElasticSearch都已經內置，不要通過配置去定義。舉個例子來說，在Solr中我要想定義一個名字為name，類型為string的field，我需要在managed_schema(xml)中配置兩個東西：

也就是說，Solr預設的字段類型仍然需要自己去定義使用Solr中的那個類，比如上面的第一行定義了string這個類型使用了solr.StrField這個類。然后我才能指定id field的type為string。如果我想惡作劇把string定義為solr.IntPointField（int類型）來迷惑大家可以嗎？當然可以。而在ElasticSearch中，各種類型都已經預定義好，我們只需要一個json的mapping來指定field的類型就好（keyword即不分詞的string）。

PUT my_index{  "mappings": {    "properties": {      "name": {        "type":  "keyword"      }    }  }}

Solr的配置感覺上更加Geek，因為他一般都是直接配置java類。而ElasticSearch包裝更好，各種類型都已經預制好。Solr的讀寫鏈路都可以深度定制，你可以在讀寫鏈路上增加各種Processor和Component來添加各種不同的功能。你甚至可以定義處理你請求的handler類。

              true      false              terms      

比如上面定義"/terms"路徑將由solr.SearchHandler這個類來處理，同時在Search的component中加入了一個叫做solr.TermsComponent的組件。如果你愿意的話，你可以為每個Collection在訪問“/terms”這個路徑時，提供完全不同的行為。

再比如下面的配置可以定義一個文檔在寫入時需要經過的Processor（如果熟悉HBase的話，你可以認為就是HBase的Coprocessor）

Solr的整條讀寫鏈路都是通過這種配置文件定義的，定制化非常自由，以至于如果配置不好，會把正常的讀寫鏈路給配置沒掉。所以Solr在文檔中警告，如果你在使用的updateRequestProcessorChain中沒有配置RunUpdateProcessorFactory的話，寫入請求是不會真正被執行的……

而ElasticSearch很多功能都是開箱即用，并不需要用戶去配置。Solr的配置太過于靈活，給了用戶很多犯錯誤的可能，而ElasticSearch的設計哲學是盡量減少用戶犯錯的可能，ES對運行環境還做了諸多限制，以避免運行過程中出現一些莫名其妙的錯誤，因為很多用戶并不是這些領域的專家，他們沒法從這些錯誤中找到原因。比如說ElasticSearch在啟動時會做memory check，系統是否限制了file descriptor數等等，甚至如果運行的是某個有已知bug的JVM版本，ElasticSearch也會拒絕啟動。ElasticSearch在啟動時還會用JarHell去檢查加載的類里是否有同名類，我曾經在自己的測試工程中集成了ElasticSearch想來啟動一個本地的ES集群，著實被JarHell惡心了一把，在一個大的Java工程里，各種不同的依賴，不出現同名類確實太難。花了半天按照JarHell的報錯提示去exclude依賴之后終于放棄，JarHell檢查還不能被關閉，我只能fake了一個空的JarHell類繞過檢查。總而言之，ES降低了使用門檻，同時還極力避免用戶犯錯，對新手友好。

• Solr支持HDFS存儲而ElasticSearch不能

Solr能夠支持HDFS做為存儲是Solr的一大特點，on HDFS帶來了存儲計算分離的優勢。比如說，在普通存儲上，move一個replica從一個節點到另外一個節點意味著大量的數據拷貝。而如果on HDFS的話，move一個replica并不需要移動任何數據，每個節點都可以讀到HDFS上的內容，另外一個節點只需要打開HDFS上的數據即可。當Solr on HDFS后，配上AutoScalling框架，其實只需要一個主replica即可（如果不是想分散讀壓力的話）。因為一臺node掛掉之后，Shard在另外一個節點快速上線，不需要拷貝數據。當我要balance整個集群時，整個過程也非常快，因為只有邏輯上的shard在節點中流動，而數據在HDFS是不需要移動的。在這個點上，ElasticSearch沒有on HDFS的能力，因此這些他都做不到。

• Solr支持Shard split而ElasticSearch不能

雖然說Solr/ES的shard是hash分片（根據doc id或者用戶自定義的field），天生就可以分散熱點。但是仍然可能存在某一些doc比較熱，需要分散熱點。或者說如果集群中加入一批新的機器，需要分更多的shard才能保證Collection能夠利用到集群中的每一臺。而Solr是支持Shard做split操作，能夠將一個Shard分成多個。而ElasticSearch卻不可以做shard的split，如果一個Index想要更多的shard，只能新建一個擁有更多shard的index，然后將數據遷移過去。為什么ElasticSearch不能做這樣的操作？這是他們的路由策略決定的。Solr的分片定義了hash的范圍，split時可以將范圍分半，切分出兩個子shard來分別負責這兩段范圍。而ElasticSearch的路由是hash后再對shard取mod，來決定落在哪個shard上，這導致如果新加了shard，取mod就會亂掉。ElasticSearch的shard不能分裂以為這在做規劃時需要非常小心地預估自己的Index將來有多少數據，需要多少個shard。一旦估算錯誤，后期遷移需要大量拷貝數據。

• ES支持功能和生態更為豐富

ElasticSearch的功能豐富程度確實令人咋舌，畢竟后面有一家非常強大的商業公司。為了吸引客戶，什么事情都干得出來（褒義）。ELK套間在Log處理這塊已經是業界通用的解決方案。同時，Elastic公司還通過X-Pack給不同層級的用戶提供了尤為豐富的功能。而Solr背后雖然有一些商業化公司，比如LucidWorks，但總的來說還是沒有Elastic知名，提供的解決方案也比較有限。我在這里列舉一些ElasticSearch中比較優秀的功能：

1. 對JSON友好：支持nested field，天生和JSON契合，而Solr中只支持nested docment。

2. 支持Index Sorting：我覺得這個是在排序場景下的殺手級功能。如果用戶的請求都會帶有某個field的排序條件，ElasticSearch可以在Segment中不是按doc ID排序，而是按照這個field排序。從而在查詢過程中，能夠掃描前n條就可以獲得快速獲得結果集，從而提前完成查詢。

3. 支持Index的life cycle管理：例如超過多少天，自動刪除Index，如果Index很hot，則增加replica。或者定時對index做一個snapshot等等。

4. 支持時序數據降精度：ElasticSearch針對時序數據領域的重磅功能。能夠支持配置rollup background job，對一些field數據做聚合，比如把小時數據聚合成天的存儲在另外field或者Index中。

5. 支持觸發器：當特定的條件滿足時，可以做出一系列事件，比如curl一個網頁，從而實現類似數據庫觸發器的功能。

到此，相信大家對“Solr與ElasticSearch有哪些異同點”有了更深的了解，不妨來實際操作一番吧！這里是創新互聯網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！