我們為什麼在這裡？我存在的目的是什麼？我應該運動還是休息並節省能量？早起上班或晚起並整夜工作？我應該將炸薯條和番茄醬或蛋黃醬一起吃嗎？
這些都是古老的問題，可能有也可能沒有答案。其中一些是非常困難或非常主觀的。但是，讓我付出一些努力來嘗試回答其中之一：我應該使用Elasticsearch還是Solr？
這是場景。您的組織正在尋求實現您的第一個搜索引擎，並切換到另一個搜索引擎-呼籲所有Google Search Appliance（GSA）用戶尋找替代品！ -或嘗試通過開源來省錢。作為一個熟練而有能力的開發人員，您已經被要求解決一個難題。您的問題有許多業務需求，但從根本上講，這是一個“大數據和搜索”問題。
您需要從多個數據源中提取大量內容，並從這些數據中獲取見解，以幫助您的公司發展並實現其今年的目標。
一擊致命
這裡有很多危險。您不會錯過任何一個鏡頭。您需要合適的搜索引擎來工作，您正在考慮開放源代碼，並且有兩個受歡迎的選擇：Elasticsearch或Solr，根據DB-的說法，這兩個都穩居開放源和商業搜索引擎的前兩位。引擎。
您會選擇哪個開源搜索引擎？
這不是拋硬幣也不是容易的選擇。兩種搜索引擎都很棒，沒有一個“正確”的選擇。這完全取決於您的要求。
因此，第一步是瞭解您必須構建什麼應用程序。然後，下一步是查看每個搜索引擎必須提供的功能。順便說一句，如果您仍處於開源與商業解決方案的交匯處，請獲取我們的免費電子書，以深入瞭解選擇搜索引擎時要考慮的10個關鍵標準。
功能概要
幾年前，我們寫了一個關於Elasticsearch vs. Solr的高級概述博客，其中討論了總體趨勢和非技術見解。現在，隨著Elasticsearch的發展壯大併成為開放源代碼搜索引擎市場的主導者，讓我們重新審視一下每個領域，看看它將帶給我們什麼。
年齡和成熟度
在這種情況下，可以說Solr的歷史悠久，它由CNET Networks的Yonik Seely於2004年創建，後來在2006年將其貢獻給Apache。它最終在2007年畢業於頂級項目。我們擁有的是Elasticsearch，該軟件於2010年正式創建，儘管它實際上是由其創始人Shay Bannon於2001年以Compass的名字開始的。從那時起，Kibana，Logstash和Beats的創建者加入了Elasticsearch，創建了Elastic Stack產品系列，該產品系列已成為搜索和日誌分析領域的強大參與者。話雖如此，Solr的優勢在於可以較早地在市場上看到。
社區和開源
兩者都有非常活躍的社區。如果您查看Github，您會發現它們是非常受歡迎的開源項目，發佈了很多版本。
一個非常重要的細節是，儘管兩者都是在Apache許可下發布的，並且都是開源的，但是它們的工作方式卻有所不同。 Solr確實是開源的-任何人都可以提供幫助和貢獻。使用Elasticsearch，儘管人們仍然可以提供他們的捐款，但是隻有Elastic的員工（Elasticsearch和Elastic Stack背後的公司）可以接受這些捐款。
這是好事還是壞事？這取決於你怎麼看了。這意味著，如果有您需要的功能，並且您以足夠的質量向社區做出了貢獻，那麼它可以被Solr接受。藉助Elasticsearch，由Elastic來決定是否接受捐助。因此，Solr上可能有更多功能選項。另一方面，對Elasticsearch的貢獻要經過更高級別的質量檢查，可能會提供更高的一致性和質量。
文獻資料
Elasticsearch和Solr都有文檔齊全的參考指南。 Elasticsearch在Github之上運行，而Solr使用Atlassian Confluence。您可以通過下面的鏈接找到它們。
Elasticsearch參考指南
Solr參考指南
核心技術
讓我們多一點技術。 Elasticsearch和Solr是兩個不同的搜索引擎。但在下面，它們都使用Lucene，這意味著兩者都建立在“巨人的肩膀”上。
對於那些想知道為什麼我將Lucene視為“巨人”的人來說，它是許多搜索引擎支持下的實際信息檢索軟件庫。它非常快速，穩定，並且可能無法比這更好。 Lucene是由Hadoop的創建者之一Doug Cutting於1999年創建的。因此，Lucene是在搜索引擎中使用的理想選擇。
Java API和REST
Elasticsearch具有更多的“ Web 2.0” REST API，但是Solr的SolrJ確實有更好的Java API-如果使用Microsoft技術，則為SolrNet。 Elasticsearch擁有Nest和Elasticsearch.Net。 Solr的REST API可能沒有那麼靈活，但是它可以很好地滿足您的需求：建立索引和查詢。 Elasticsearch會說JSON，因此，如果您周圍都使用JSON，那麼這是一個不錯的選擇。 Solr也支持JSON，但是它是在以後的階段添加的，因為它最初是針對XML的。
內容處理
內容處理由於它們都公開了API，因此很容易從您的自定義應用程序或已經存在且可配置的應用程序中索引內容。例如，我們的Aspire內容處理框架能夠連接到多個數據源併發布到Elasticsearch或Solr。
Solr還具有使用Apache Tika從二進制文件提取文本的功能。因此，您可以通過ExtractRequestHandler上傳PDF，Solr將知道如何處理它。
另一方面，Elasticsearch與Logstash配合良好，後者可以處理任何來源的數據併為其編制索引。
可擴展性
縮放是一個關鍵的考慮因素。在這種情況下，當Solr仍然受限於Master-Slave時，Elasticsearch贏得了比賽。但是，SolrCloud最近才進入遊戲。在Zookeeper的幫助下，現在可以以更加輕鬆快捷的方式擴展Solr集群-與具有Master-Slave的舊版本Solr相比，這是一個增強。仍然需要進行大量改進，但是就可以在Solr中攝取和搜索的數據集的大小而言，前途一片光明。
供應商支持
有幾家公司不得不決定哪種產品最適合他們。例如，Cloudera選擇了Solr作為他們的搜索引擎，以集成到開源CDH（包括Hadoop的Cloudera Distribution）中。另一方面，還有其他供應商選擇Elasticsearch作為其解決方案的搜索引擎。 Search Technologies的我們將為兩個搜索引擎提供諮詢，部署和支持。
願景與生態
Solr更加側重於文本搜索。 Elasticsearch迅速樹立了自己的利基市場，通過創建Elastic Stack（以前稱為ELK Stack）來進行日誌分析，Elastic Stack代表Elasticsearch，Logstash，Kibana和Beats。雙方都有清晰的願景，並且正在朝著自己的方向大步前進。
值得重申的一件事是，如何將兩個搜索引擎用作許多領先搜索和大數據平臺的基礎。例如，Elasticsearch是Microsoft Azure搜索的一部分，而Solr已集成到Cloudera Search中。
性能
在性能方面，根據我從許多開發人員那裡獲得的經驗，我們可以說這兩個引擎都表現出色。因此，對於大多數用例而言，無論是內部還是外部搜索應用程序，只要開發人員正確設計和配置它們，性能都不會成為問題。
網絡管理
Solr捆綁了Web管理，而Elasticsearch還有其他多個高級插件可用於安全性，警報和監視。此列表展示了Elastic的整個產品系列。
可視化
有許多方法可以在Elasticsearch和Solr中可視化數據-您可以構建自定義可視化儀表板，也可以使用搜索引擎的標準可視化功能（可能需要進行一些調整）。但是有一個區別值得一提。
Solr主要專注於文本搜索。它在這方面做得很好，成為了搜索應用程序的標準。但是，Elasticsearch朝著另一個方向發展，它超越了搜索範圍，可以通過Elastic Stack解決日誌分析和可視化問題。以下是您可以使用Kibana 5進行的一些可視化處理。
這並不意味著一個人勝於另一個。 它僅表示每個搜索引擎在不同的用例和需求中都有自己的優勢，而您的選擇將在很大程度上取決於您的組織要完成的工作。
長話短說，Elasticsearch和Solr都是出色的開源選擇，將幫助您從數據中獲取更多收益。 這完全取決於您的要求，預算，時間安排以及項目的複雜性。
有用的資源
- 這本電子書詳細介紹了選擇搜索引擎的關鍵條件。 它可以幫助指導您完成決策過程。
- 如果您正在尋找評估搜索引擎和實施方案的專家幫助，請與我們聯繫以詳細瞭解我們的評估。
原文：https://www.searchtechnologies.com/blog/solr-vs-elasticsearch-top-open-source-search
本文：http://jiagoushi.pro/node/908
討論：請加入知識星球或者微信圈子【首席架構師圈】
閱讀更多 首席架構師 的文章
