這篇文章主要講解了“ElasticSearch和Solr的優(yōu)缺點(diǎn)有哪些”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“ElasticSearch和Solr的優(yōu)缺點(diǎn)有哪些”吧！

創(chuàng)新互聯(lián)公司專(zhuān)注為客戶(hù)提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站制作、做網(wǎng)站、大理州網(wǎng)絡(luò)推廣、小程序開(kāi)發(fā)、大理州網(wǎng)絡(luò)營(yíng)銷(xiāo)、大理州企業(yè)策劃、大理州品牌公關(guān)、搜索引擎seo、人物專(zhuān)訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供大理州建站搭建服務(wù)，24小時(shí)服務(wù)熱線(xiàn)：18982081108，官方網(wǎng)址：www.rwnh.cn

由 ReyCG 精心繪制并提供

什么是全文搜索

什么是全文搜索引擎？百度百科中的定義：

全文搜索引擎是目前廣泛應(yīng)用的主流搜索引擎。它的工作原理是計(jì)算機(jī)索引程序通過(guò)掃描文章中的每一個(gè)詞，對(duì)每一個(gè)詞建立一個(gè)索引，指明該詞在文章中出現(xiàn)的次數(shù)和位置，當(dāng)用戶(hù)查詢(xún)時(shí)，檢索程序就根據(jù)事先建立的索引進(jìn)行查找，并將查找的結(jié)果反饋給用戶(hù)的檢索方式。這個(gè)過(guò)程類(lèi)似于通過(guò)字典中的檢索字表查字的過(guò)程。

從定義中我們已經(jīng)可以大致了解全文檢索的思路了，為了更詳細(xì)的說(shuō)明，我們先從生活中的數(shù)據(jù)說(shuō)起。

我們生活中的數(shù)據(jù)總體分為兩種：

•  結(jié)構(gòu)化數(shù)據(jù)：指具有固定格式或有限長(zhǎng)度的數(shù)據(jù)，如數(shù)據(jù)庫(kù)，元數(shù)據(jù)等。

•  非結(jié)構(gòu)化數(shù)據(jù)：非結(jié)構(gòu)化數(shù)據(jù)又可稱(chēng)為全文數(shù)據(jù)，指不定長(zhǎng)或無(wú)固定格式的數(shù)據(jù)，如郵件，Word 文檔等。

當(dāng)然有的地方還會(huì)有第三種：半結(jié)構(gòu)化數(shù)據(jù)，如 XML，HTML 等，當(dāng)根據(jù)需要可按結(jié)構(gòu)化數(shù)據(jù)來(lái)處理，也可抽取出純文本按非結(jié)構(gòu)化數(shù)據(jù)來(lái)處理。

根據(jù)兩種數(shù)據(jù)分類(lèi)，搜索也相應(yīng)的分為兩種：結(jié)構(gòu)化數(shù)據(jù)搜索和非結(jié)構(gòu)化數(shù)據(jù)搜索。

對(duì)于結(jié)構(gòu)化數(shù)據(jù)，我們一般都是可以通過(guò)關(guān)系型數(shù)據(jù)庫(kù)(MySQL，Oracle 等)的 table 的方式存儲(chǔ)和搜索，也可以建立索引。

對(duì)于非結(jié)構(gòu)化數(shù)據(jù)，也即對(duì)全文數(shù)據(jù)的搜索主要有兩種方法：

•  順序掃描
  

•  全文檢索

  順序掃描：通過(guò)文字名稱(chēng)也可了解到它的大概搜索方式，即按照順序掃描的方式查詢(xún)特定的關(guān)鍵字。

例如給你一張報(bào)紙，讓你找到該報(bào)紙中“RNG”的文字在哪些地方出現(xiàn)過(guò)。你肯定需要從頭到尾把報(bào)紙閱讀掃描一遍，然后標(biāo)記出關(guān)鍵字在哪些版塊出現(xiàn)過(guò)以及它的出現(xiàn)位置。

這種方式無(wú)疑是最耗時(shí)的最低效的，如果報(bào)紙排版字體小，而且版塊較多甚至有多份報(bào)紙，等你掃描完你的眼睛也差不多了。

•  全文檢索：對(duì)非結(jié)構(gòu)化數(shù)據(jù)順序掃描很慢，我們是否可以進(jìn)行優(yōu)化？把我們的非結(jié)構(gòu)化數(shù)據(jù)想辦法弄得有一定結(jié)構(gòu)不就行了嗎？

將非結(jié)構(gòu)化數(shù)據(jù)中的一部分信息提取出來(lái)，重新組織，使其變得有一定結(jié)構(gòu)，然后對(duì)此有一定結(jié)構(gòu)的數(shù)據(jù)進(jìn)行搜索，從而達(dá)到搜索相對(duì)較快的目的。

這種方式就構(gòu)成了全文檢索的基本思路。這部分從非結(jié)構(gòu)化數(shù)據(jù)中提取出的然后重新組織的信息，我們稱(chēng)之索引。

還以讀報(bào)紙為例，我們想關(guān)注英雄聯(lián)盟 S8 全球總決賽的新聞，假如都是 RNG 的粉絲，如何快速找到 RNG 新聞的報(bào)紙和版塊呢？

全文檢索的方式就是，將所有報(bào)紙中所有版塊中關(guān)鍵字進(jìn)行提取，如"EDG"，"RNG"，"FW"，"戰(zhàn)隊(duì)"，"英雄聯(lián)盟"等。

然后對(duì)這些關(guān)鍵字建立索引，通過(guò)索引我們就可以對(duì)應(yīng)到該關(guān)鍵詞出現(xiàn)的報(bào)紙和版塊。注意區(qū)別目錄搜索引擎。

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

之前，有同事問(wèn)我，為什么要用搜索引擎？我們的所有數(shù)據(jù)在數(shù)據(jù)庫(kù)里面都有，而且 Oracle、SQL Server 等數(shù)據(jù)庫(kù)里也能提供查詢(xún)檢索或者聚類(lèi)分析功能，直接通過(guò)數(shù)據(jù)庫(kù)查詢(xún)不就可以了嗎？

確實(shí)，我們大部分的查詢(xún)功能都可以通過(guò)數(shù)據(jù)庫(kù)查詢(xún)獲得，如果查詢(xún)效率低下，還可以通過(guò)建數(shù)據(jù)庫(kù)索引，優(yōu)化 SQL 等方式提升效率，甚至通過(guò)引入緩存來(lái)加快數(shù)據(jù)的返回速度。

如果數(shù)據(jù)量更大，就可以分庫(kù)分表來(lái)分擔(dān)查詢(xún)壓力。那為什么還要全文搜索引擎呢？我們主要從以下幾個(gè)原因分析：

數(shù)據(jù)類(lèi)型

全文索引搜索支持非結(jié)構(gòu)化數(shù)據(jù)的搜索，可以更好地快速搜索大量存在的任何單詞或單詞組的非結(jié)構(gòu)化文本。

例如 Google，百度類(lèi)的網(wǎng)站搜索，它們都是根據(jù)網(wǎng)頁(yè)中的關(guān)鍵字生成索引，我們?cè)谒阉鞯臅r(shí)候輸入關(guān)鍵字，它們會(huì)將該關(guān)鍵字即索引匹配到的所有網(wǎng)頁(yè)返回；還有常見(jiàn)的項(xiàng)目中應(yīng)用日志的搜索等等。

對(duì)于這些非結(jié)構(gòu)化的數(shù)據(jù)文本，關(guān)系型數(shù)據(jù)庫(kù)搜索不是能很好的支持。

索引的維護(hù)

一般傳統(tǒng)數(shù)據(jù)庫(kù)，全文檢索都實(shí)現(xiàn)的很雞肋，因?yàn)橐话阋矝](méi)人用數(shù)據(jù)庫(kù)存文本字段。

進(jìn)行全文檢索需要掃描整個(gè)表，如果數(shù)據(jù)量大的話(huà)即使對(duì) SQL 的語(yǔ)法優(yōu)化，也收效甚微。

建立了索引，但是維護(hù)起來(lái)也很麻煩，對(duì)于 insert 和 update 操作都會(huì)重新構(gòu)建索引。

什么時(shí)候使用全文搜索引擎：

•  搜索的數(shù)據(jù)對(duì)象是大量的非結(jié)構(gòu)化的文本數(shù)據(jù)。

•  文件記錄量達(dá)到數(shù)十萬(wàn)或數(shù)百萬(wàn)個(gè)甚至更多。

•  支持大量基于交互式文本的查詢(xún)。

•  需要非常靈活的全文搜索查詢(xún)。

•  對(duì)高度相關(guān)的搜索結(jié)果有特殊需求，但是沒(méi)有可用的關(guān)系數(shù)據(jù)庫(kù)可以滿(mǎn)足。

•  對(duì)不同記錄類(lèi)型、非文本數(shù)據(jù)操作或安全事務(wù)處理的需求相對(duì)較少的情況。

Lucene，Solr，ElasticSearch ？

現(xiàn)在主流的搜索引擎大概就是：Lucene，Solr，ElasticSearch。

圖片

它們的索引建立都是根據(jù)倒排索引的方式生成索引，何謂倒排索引？

維基百科：倒排索引（英語(yǔ)：Inverted index），也常被稱(chēng)為反向索引、置入檔案或反向檔案，是一種索引方法，被用來(lái)存儲(chǔ)在全文搜索下某個(gè)單詞在一個(gè)文檔或者一組文檔中的存儲(chǔ)位置的映射。它是文檔檢索系統(tǒng)中最常用的數(shù)據(jù)結(jié)構(gòu)。

Lucene

Lucene 是一個(gè) Java 全文搜索引擎，完全用 Java 編寫(xiě)。Lucene 不是一個(gè)完整的應(yīng)用程序，而是一個(gè)代碼庫(kù)和 API，可以很容易地用于向應(yīng)用程序添加搜索功能。Lucene 通過(guò)簡(jiǎn)單的 API 提供強(qiáng)大的功能：

可擴(kuò)展的高性能索引：

•  在現(xiàn)代硬件上超過(guò) 150GB /小時(shí)。

•  小 RAM 要求，只有 1MB 堆。

•  增量索引與批量索引一樣快。

•  索引大小約為索引文本大小的 20-30％。

強(qiáng)大，準(zhǔn)確，高效的搜索算法：

•  排名搜索：首先返回最佳結(jié)果。

•  許多強(qiáng)大的查詢(xún)類(lèi)型：短語(yǔ)查詢(xún)，通配符查詢(xún)，鄰近查詢(xún)，范圍查詢(xún)等。

•  現(xiàn)場(chǎng)搜索（例如標(biāo)題，作者，內(nèi)容）。

•  按任何字段排序。

•  使用合并結(jié)果進(jìn)行多索引搜索。

•  允許同時(shí)更新和搜索。

•  靈活的分面，突出顯示，連接和結(jié)果分組。

•  快速，內(nèi)存效率和錯(cuò)誤容忍的建議。

•  可插拔排名模型，包括矢量空間模型和 Okapi BM25。

•  可配置存儲(chǔ)引擎（編解碼器）。

跨平臺(tái)解決方案：

•  作為 Apache 許可下的開(kāi)源軟件提供 ，允許您在商業(yè)和開(kāi)源程序中使用 Lucene。

•  100％-pure Java。

•  可用的其他編程語(yǔ)言中的實(shí)現(xiàn)是索引兼容的。

Apache 軟件基金會(huì)：

•  獲得 Apache 軟件基金會(huì)提供的開(kāi)源軟件項(xiàng)目的 Apache 社區(qū)的支持。

•  但是 Lucene 只是一個(gè)框架，要充分利用它的功能，需要使用 Java，并且在程序中集成 Lucene。

        需要很多的學(xué)習(xí)了解，才能明白它是如何運(yùn)行的，熟練運(yùn)用 Lucene 確實(shí)非常復(fù)雜。

Solr

Apache Solr 是一個(gè)基于名為 Lucene 的 Java 庫(kù)構(gòu)建的開(kāi)源搜索平臺(tái)。它以用戶(hù)友好的方式提供 Apache Lucene 的搜索功能。

作為一個(gè)行業(yè)參與者已近十年，它是一個(gè)成熟的產(chǎn)品，擁有強(qiáng)大而廣泛的用戶(hù)社區(qū)。

它提供分布式索引，復(fù)制，負(fù)載平衡查詢(xún)以及自動(dòng)故障轉(zhuǎn)移和恢復(fù)。如果它被正確部署然后管理得好，它就能夠成為一個(gè)高度可靠，可擴(kuò)展且容錯(cuò)的搜索引擎。

很多互聯(lián)網(wǎng)巨頭，如 Netflix，eBay，Instagram 和亞馬遜（CloudSearch）都使用 Solr，因?yàn)樗軌蛩饕退阉鞫鄠€(gè)站點(diǎn)。

主要功能列表包括：

•  全文搜索

•  突出

•  分面搜索

•  實(shí)時(shí)索引

•  動(dòng)態(tài)群集

•  數(shù)據(jù)庫(kù)集成

•  NOSQL 功能和豐富的文檔處理（例如 Word 和 PDF 文件）

ElasticSearch

Elasticsearch 是一個(gè)開(kāi)源（Apache 2 許可證），基于 Apache Lucene 庫(kù)構(gòu)建的 RESTful 搜索引擎。

Elasticsearch 是在 Solr 之后幾年推出的。它提供了一個(gè)分布式，多租戶(hù)能力的全文搜索引擎，具有 HTTP Web 界面（REST）和無(wú)架構(gòu) JSON 文檔。

Elasticsearch 的官方客戶(hù)端庫(kù)提供 Java，Groovy，PHP，Ruby，Perl，Python，.NET 和 Javascript。

分布式搜索引擎包括可以劃分為分片的索引，并且每個(gè)分片可以具有多個(gè)副本。

每個(gè) Elasticsearch 節(jié)點(diǎn)都可以有一個(gè)或多個(gè)分片，其引擎也可以充當(dāng)協(xié)調(diào)器，將操作委派給正確的分片。

Elasticsearch 可通過(guò)近實(shí)時(shí)搜索進(jìn)行擴(kuò)展。其主要功能之一是多租戶(hù)。主要功能列表包括：

•  分布式搜索

•  多租戶(hù)

•  分析搜索

•  分組和聚合

Elasticsearch vs Solr 的選擇

由于 Lucene 的復(fù)雜性，一般很少會(huì)考慮它作為搜索的第一選擇，排除一些公司需要自研搜索框架，底層需要依賴(lài) Lucene。

所以這里我們重點(diǎn)分析哪一個(gè)更好？它們有什么不同？你應(yīng)該使用哪一個(gè)？

圖片

歷史比較

Apache Solr 是一個(gè)成熟的項(xiàng)目，擁有龐大而活躍的開(kāi)發(fā)和用戶(hù)社區(qū)，以及 Apache 品牌。

Solr 于 2006 年首次發(fā)布到開(kāi)源，長(zhǎng)期以來(lái)一直占據(jù)著搜索引擎領(lǐng)域，并且是任何需要搜索功能的人的首選引擎。

它的成熟轉(zhuǎn)化為豐富的功能，而不僅僅是簡(jiǎn)單的文本索引和搜索；如分面，分組，強(qiáng)大的過(guò)濾，可插入的文檔處理，可插入的搜索鏈組件，語(yǔ)言檢測(cè)等。

Solr 在搜索領(lǐng)域占據(jù)了多年的主導(dǎo)地位。然后，在 2010 年左右，Elasticsearch 成為市場(chǎng)上的另一種選擇。

那時(shí)候，它遠(yuǎn)沒(méi)有 Solr 那么穩(wěn)定，沒(méi)有 Solr 的功能深度，沒(méi)有思想分享，品牌等等。

Elasticsearch 雖然很年輕，但它也自己的一些優(yōu)勢(shì)，Elasticsearch 建立在更現(xiàn)代的原則上，針對(duì)更現(xiàn)代的用例，并且是為了更容易處理大型索引和高查詢(xún)率而構(gòu)建的。

此外，由于它太年輕，沒(méi)有社區(qū)可以合作，它可以自由地向前推進(jìn)，而不需要與其他人（用戶(hù)或開(kāi)發(fā)人員）達(dá)成任何共識(shí)或合作，向后兼容，或任何其他更成熟的軟件通常必須處理。

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

從技術(shù)上講，NRT 搜索的能力確實(shí)來(lái)自 Lucene，它是 Solr 和 Elasticsearch 使用的基礎(chǔ)搜索庫(kù)。

具有諷刺意味的是，因?yàn)?Elasticsearch 首先公開(kāi)了 NRT 搜索，所以人們將 NRT 搜索與 Elasticsearch 聯(lián)系在一起。

盡管 Solr 和 Lucene 都是同一個(gè) Apache 項(xiàng)目的一部分，但是，人們會(huì)首先期望 Solr 具有如此高要求的功能。

特征差異比較

這兩個(gè)搜索引擎都是流行的，先進(jìn)的的開(kāi)源搜索引擎。它們都是圍繞核心底層搜索庫(kù) Lucene 構(gòu)建的，但它們又是不同的。

像所有東西一樣，每個(gè)都有其優(yōu)點(diǎn)和缺點(diǎn)，根據(jù)您的需求和期望，每個(gè)都可能更好或更差。

Solr 和 Elasticsearch 都在快速發(fā)展，所以，話(huà)不多說(shuō)，先來(lái)看下它們的差異清單：

圖片

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

綜合比較

另外，我們?cè)購(gòu)囊韵聨讉€(gè)方面來(lái)分析下：

①近幾年的流行趨勢(shì)

我們查看一下這兩種產(chǎn)品的 Google 搜索趨勢(shì)。谷歌趨勢(shì)表明，與 Solr 相比，Elasticsearch 具有很大的吸引力，但這并不意味著 Apache Solr 已經(jīng)死亡。

雖然有些人可能不這么認(rèn)為，但 Solr 仍然是最受歡迎的搜索引擎之一，擁有強(qiáng)大的社區(qū)和開(kāi)源支持。

圖片

②安裝和配置

與 Solr 相比，Elasticsearch 易于安裝且非常輕巧。此外，您可以在幾分鐘內(nèi)安裝并運(yùn)行 Elasticsearch。

但是，如果 Elasticsearch 管理不當(dāng)，這種易于部署和使用可能會(huì)成為一個(gè)問(wèn)題。

基于 JSON 的配置很簡(jiǎn)單，但如果要為文件中的每個(gè)配置指定注釋?zhuān)敲此贿m合您。

總的來(lái)說(shuō)，如果您的應(yīng)用使用的是 JSON，那么 Elasticsearch 是一個(gè)更好的選擇。

否則，請(qǐng)使用 Solr，因?yàn)樗?schema.xml 和 solrconfig.xml 都有很好的文檔記錄。

③社區(qū)

Solr 擁有更大，更成熟的用戶(hù)，開(kāi)發(fā)者和貢獻(xiàn)者社區(qū)。ES 雖擁有的規(guī)模較小但活躍的用戶(hù)社區(qū)以及不斷增長(zhǎng)的貢獻(xiàn)者社區(qū)。

Solr 是真正的開(kāi)源社區(qū)代表。任何人都可以為 Solr 做出貢獻(xiàn)，并且根據(jù)優(yōu)點(diǎn)選出新的 Solr 開(kāi)發(fā)人員（也稱(chēng)為提交者）。

Elasticsearch 在技術(shù)上是開(kāi)源的，但在精神上卻不那么重要。任何人都可以看到來(lái)源，任何人都可以更改它并提供貢獻(xiàn)，但只有 Elasticsearch 的員工才能真正對(duì) Elasticsearch 進(jìn)行更改。

Solr 貢獻(xiàn)者和提交者來(lái)自許多不同的組織，而 Elasticsearch 提交者來(lái)自單個(gè)公司。

④成熟度

Solr 更成熟，但 ES 增長(zhǎng)迅速，我認(rèn)為它穩(wěn)定。

⑤文檔

Solr 在這里得分很高。它是一個(gè)非常有據(jù)可查的產(chǎn)品，具有清晰的示例和 API 用例場(chǎng)景。

Elasticsearch 的文檔組織良好，但它缺乏好的示例和清晰的配置說(shuō)明。

總結(jié)

那么，到底是選擇 Solr 還是 Elasticsearch？有時(shí)很難找到明確的答案。無(wú)論您選擇 Solr 還是 Elasticsearch，首先需要了解正確的用例和未來(lái)需求，總結(jié)它們的每個(gè)屬性。

記住下面這些要點(diǎn)：

•  由于易于使用，Elasticsearch 在新開(kāi)發(fā)者中更受歡迎。但是，如果您已經(jīng)習(xí)慣了與 Solr 合作，請(qǐng)繼續(xù)使用它，因?yàn)檫w移到 Elasticsearch 沒(méi)有特定的優(yōu)勢(shì)。

•  如果除了搜索文本之外還需要它來(lái)處理分析查詢(xún)，Elasticsearch 是更好的選擇。

•  如果需要分布式索引，則需要選擇 Elasticsearch。對(duì)于需要良好可伸縮性和性能的云和分布式環(huán)境，Elasticsearch 是更好的選擇。

•  兩者都有良好的商業(yè)支持（咨詢(xún)，生產(chǎn)支持，整合等）。

•  兩者都有很好的操作工具，盡管 Elasticsearch 因其易于使用的 API 而更多地吸引了 DevOps 人群，因此可以圍繞它創(chuàng)建一個(gè)更加生動(dòng)的工具生態(tài)系統(tǒng)。

•  Elasticsearch 在開(kāi)源日志管理用例中占據(jù)主導(dǎo)地位，許多組織在 Elasticsearch 中索引它們的日志以使其可搜索。雖然 Solr 現(xiàn)在也可以用于此目的，但它只是錯(cuò)過(guò)了這一想法。

•  Solr 仍然更加面向文本搜索。另一方面，Elasticsearch 通常用于過(guò)濾和分組，分析查詢(xún)工作負(fù)載，而不一定是文本搜索。

•  Elasticsearch 開(kāi)發(fā)人員在 Lucene 和 Elasticsearch 級(jí)別上投入了大量精力使此類(lèi)查詢(xún)更高效(降低內(nèi)存占用和 CPU 使用)。

•  因此，對(duì)于不僅需要進(jìn)行文本搜索，而且需要復(fù)雜的搜索時(shí)間聚合的應(yīng)用程序，Elasticsearch 是一個(gè)更好的選擇。

•  Elasticsearch 更容易上手，一個(gè)下載和一個(gè)命令就可以啟動(dòng)一切。Solr 傳統(tǒng)上需要更多的工作和知識(shí)，但 Solr 最近在消除這一點(diǎn)上取得了巨大的進(jìn)步，現(xiàn)在只需努力改變它的聲譽(yù)。

•  在性能方面，它們大致相同。我說(shuō)“大致”，因?yàn)闆](méi)有人做過(guò)全面和無(wú)偏見(jiàn)的基準(zhǔn)測(cè)試。對(duì)于 95％ 的用例，任何一種選擇在性能方面都會(huì)很好，剩下的 5％ 需要用它們的特定數(shù)據(jù)和特定的訪問(wèn)模式來(lái)測(cè)試這兩種解決方案。

•  從操作上講，Elasticsearch 使用起來(lái)比較簡(jiǎn)單，它只有一個(gè)進(jìn)程。Solr 在其類(lèi)似 Elasticsearch 的完全分布式部署模式 SolrCloud 中依賴(lài)于 Apache ZooKeeper，ZooKeeper 是超級(jí)成熟，超級(jí)廣泛使用等等，但它仍然是另一個(gè)活躍的部分。

•  也就是說(shuō)，如果您使用的是 Hadoop，HBase，Spark，Kafka 或其他一些較新的分布式軟件，您可能已經(jīng)在組織的某個(gè)地方運(yùn)行 ZooKeeper。

•  雖然 Elasticsearch 內(nèi)置了類(lèi)似 ZooKeeper 的組件 Xen，但 ZooKeeper 可以更好地防止有時(shí)在 Elasticsearch 集群中出現(xiàn)的可怕的裂腦問(wèn)題。

•  公平地說(shuō)，Elasticsearch 開(kāi)發(fā)人員已經(jīng)意識(shí)到這個(gè)問(wèn)題，并致力于改進(jìn) Elasticsearch 的這個(gè)方面。

•  如果您喜歡監(jiān)控和指標(biāo)，那么使用 Elasticsearch，您將會(huì)進(jìn)入天堂。這個(gè)東西比新年前夜在時(shí)代廣場(chǎng)可以擠壓的人有更多的指標(biāo)！Solr 暴露了關(guān)鍵指標(biāo)，但遠(yuǎn)不及 Elasticsearch 那么多。

總之，兩者都是功能豐富的搜索引擎，只要設(shè)計(jì)和實(shí)現(xiàn)得當(dāng)，它們或多或少都能提供相同的性能。

感謝各位的閱讀，以上就是“ElasticSearch和Solr的優(yōu)缺點(diǎn)有哪些”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)ElasticSearch和Solr的優(yōu)缺點(diǎn)有哪些這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

網(wǎng)站標(biāo)題：ElasticSearch和Solr的優(yōu)缺點(diǎn)有哪些
本文地址：http://www.rwnh.cn/article20/psgpjo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、響應(yīng)式網(wǎng)站、定制網(wǎng)站、微信小程序、手機(jī)網(wǎng)站建設(shè)、Google

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)