首先我們要明確一點，elasticsearch和solr沒有好壞之分，只有適合不適合。這是通用的道理。我們需要根據我們的實際情況來選擇最適合我們的搜尋引擎。
所以我們對elasticsearch和solr的優缺點、適用場景進行一下對比，以及我們的未來需求，來找到最合適的方案。
大部分認知中，ES代表elasticsearch，還有部分理解中ES代表elastic Stack，本文中使用ES表示elasticsearch。
Solr 優缺點
solr 優點
1. Solr有一個更大、更成熟的使用者、開發和貢獻者社群。
2. 支援新增多種格式的索引，如：HTML、PDF、微軟Office系列軟體格式以及JSON、XML、CSV等純文字格式。
3. Solr 比較成熟、穩定。
4. 不考慮建索引的同時進行搜尋，速度更快。
solr 缺點
1. 建立索引時，搜尋效率下降，實時索引搜尋訊息不高。
elasticsearch 優缺點
elasticsearch 優點
1. Elasticsearch是分散式的。不需要其他元件，分發是實時的，被叫做”Push replication”。
2. Elasticsearch 完全支援 Apache Lucene 的接近實時的搜尋。
3. 處理多租戶（multitenancy）不需要特殊配置，而Solr則需要更多的高階設定。
4. Elasticsearch 採用 Gateway 的概念，使得完備份更加簡單。
5. 各節點組成對等的網路結構，某些節點出現故障時會自動分配其他節點代替其進行工作。
elasticsearch 缺點
1. 還不夠自動（不適合當前新的Index Warmup API）
solr和elasticsearch比較
然而從上面的優缺點對比來看，我們很難發現哪一個搜尋引擎更適合我們。甚至我們對於他們的優缺點的確切概念還有些難以理解。
我們可以對solr和ES部分特性做一些對比，分析他們之間的差異性，來找到更適合我們的搜尋引擎。
流行趨勢
毫無疑問，ES已經成為全文索引的事實霸主，名氣在國內趕超Solr。
透過Google搜尋趨勢對比發現，ES比Solr更加有吸引力，Solr反而有下降的趨勢，但這並不意味著Solr已經沒落，相反，Solr仍然是最受歡迎的搜尋引擎之一。這一點我們可以從搜尋引擎排名中可以看出，當前最受歡迎的前三個搜尋引擎：Elasticsearch、Splunk和Solr中仍然包含Solr。
檢索速度
當單純的對已有資料進行搜尋時，Solr更快。
當實時建立索引時, Solr會產生io阻塞，查詢效能較差, Elasticsearch具有明顯的優勢。
隨著資料量的增加，Solr的搜尋效率會變得更低，而Elasticsearch卻沒有明顯的變化。
大型網際網路公司，實際生產環境測試，將搜尋引擎從Solr轉到Elasticsearch以後的平均查詢速度有了50倍的提升。
從目前趨勢來看，我們已經到了大資料時代，必然會面臨著海量資料，相比於Solr，ES在海量資料檢索速度方面有巨大優勢。
Solr是傳統應用的有力解決方案，但Elasticsearch更適用於新興的實時搜尋應用。
近實時搜尋
近實時搜尋一直是ES的優勢之一。然而這麼說其實沒有什麼道理，因為Solr也實現了近實時搜尋，只不過因為ES先提起這個概念，所以大家在談起近實時搜尋的時候，總是優先想起來ES。
而且實時性這個是Lucene的能力，而不是ES和Solr的。
社群
Solr擁有更多、更成熟的使用者、開發者和貢獻社群。網上可以搜到大量文件，以及問題解決案例。
ES雖然釋出時間較短，但是發展迅速，很多知名公司都在使用。社群雖然小，但是很活躍。所以完全不必擔心。elasticsearch中文社群
擴容（分散式）
ES為分散式而生，而且它的設計隱藏了分散式本身的複雜性。ES預設是叢集化的（即時是在單臺伺服器上執行，也稱之為叢集），並且總是可以新增更多的伺服器用於增加容量或者容錯性。類似的，如果負載較低的時候，可以很容易地從叢集中移除伺服器，降低成本。
SolrCloud是Solr提供的分散式搜尋方案。
當你需要大規模，容錯，分散式索引和檢索能力時使用 SolrCloud。
當索引量很大，搜尋請求併發很高時，同樣需要使用SolrCloud來滿足這些需求。
不過當一個系統的索引資料量少的時候是不需要使用SolrCloud的。
SolrCloud是基於Solr和Zookeeper的分散式搜尋方案。它的主要思想是使用Zookeeper作為SolrCloud叢集的配置資訊中心，統一管理solrcloud的配置，比如solrconfig.xml和schema.xml。
對於大多數資料庫來說，橫向擴充套件（增加新機器）意味著你的程式將做很大改動才能利用這些新新增的裝置。對比來說，ES天生就是分散式的，它知道如何管理節點來提供高擴充套件和高可用，這意味著你的程式不必要關心這些。
資料量
分散式的ElasticSearch支援的資料量確實更大，毫無疑問。但這是相對於單機版Solr來說的，分散式Solr-cloud資料量也是一樣的支援。
在這一點上，Solr和ES並沒有什麼區別。
資料聚合功能（aggregation） ☆☆☆☆☆☆☆☆
這個打這麼多☆，純粹是因為這點真是太太太突出了。
無論選擇哪個搜尋引擎，我們都有一個重要的目的：組織資料為我們的目標所服務。
ES為我們提供了一個超級棒的功能，資料聚合（aggregation）。聚合功能為ES注入了統計分析的血統，使使用者在面對大資料提取統計指標時變得遊刃有餘。
而Solr中同樣提供相似的功能Analytics Component
這也反映出，其實ES和Solr並沒有什麼太大區別。
模式
Solr中的資料是結構化的，Solr透過模式檔案schema.xml檔案來定義這種結構。
ES中的文件是無模式的，也就是說並非所有的文件都需要擁有相同的欄位，它們不是受限於同一種模式。
ES會有一種自動檢測的功能，檢測一篇新近索引的文件是否擁有一個對映中尚未存在的欄位，如果不存在，ES會自動的將新欄位加入對映。為了新增這個欄位，ES不得不確定它是什麼型別，於是ES會進行猜測。例如：如果值是7，ES會假設欄位是長整型。
這種做法的缺點是：ES可能猜的不對。例如，在索引了值7之後，你可能再索引hello world，這時由於它是string而不是long，索引就會失敗。
對於線上環境，最安全的方式是在索引資料之前，就定義好所需的對映。
配置管理 ☆
ES的一個強項是，它的預設配置對程式設計師非常友好，入門非常容容易。ElasticSearch很多功能都是開箱即用，並不需要使用者去配置。ElasticSearch的設計哲學是儘量減少使用者犯錯的可能，ES對執行環境還做了諸多限制，以避免執行過程中出現一些莫名其妙的錯誤，因為很多使用者並不是這些領域的專家，他們沒法從這些錯誤中找到原因。ES幫助我們從複雜的配置中解脫出來，將更多的時間和精力放在其他事情上。
Solr的配置太過於靈活，給了使用者很多犯錯誤的可能。但Solr的定製能力更強，幾乎什麼都可以配置。對於開發者來說，要實現一個新的功能，可以不用動Solr核心程式碼，而給Solr增加一些Processer和Component，然後透過xml配置伺服器的行為。
適用場景
網路上對兩個搜尋引擎的適用場景眾說紛紜。
奈何個人才疏學淺，無法分辨真偽。
但是有一點，Solr和ES作為當前兩個最流行的搜尋引擎，本來就是互相借鑑，共同進步，沒有明顯的差異性，沒有明顯的適用和不適用，只能說擇其善者而從之。
如果真的有，我會總結在這裡。
ES 和 Solr本質上其實並沒有什麼太大的差別，畢竟都是基於Lucene。而且這兩個搜尋引擎還在不斷迭代，該有的功能都有，只不過實現方式不一致。Solr實現了許多功能，而ES的許多功能都是透過外掛的方式實現的。
但是，誰叫ES目前更流行呢，我投ES一票！！！！！！
本作品採用《CC 協議》，轉載必須註明作者和本文連結