【騰訊WeTest干貨分享】用ElasticSearch搭建自己的搜索和分析引擎

時(shí)間：2023-05-30 11:15:01 | 來(lái)源：網(wǎng)站運(yùn)營(yíng)

時(shí)間：2023-05-30 11:15:01 來(lái)源：網(wǎng)站運(yùn)營(yíng)

【騰訊WeTest干貨分享】用ElasticSearch搭建自己的搜索和分析引擎：

導(dǎo)語(yǔ)：互聯(lián)網(wǎng)產(chǎn)品中的檢索功能隨處可見。當(dāng)你的項(xiàng)目規(guī)模是百度大搜|商搜或者微信公眾號(hào)搜索這種體量的時(shí)候，自己開發(fā)一個(gè)搜索引擎，加入各種定制的需求和優(yōu)化，是非常自然的事情。但如果只是普通的中小型項(xiàng)目甚至創(chuàng)業(yè)團(tuán)隊(duì)|創(chuàng)業(yè)項(xiàng)目，直接拿輪子則是更合理的選擇。 ElasticSearch就是這樣一個(gè)搜索引擎的輪子。更重要的是，除去常規(guī)的全文檢索功能之外，它還具有基礎(chǔ)的統(tǒng)計(jì)分析功能（最常見的就是聚合），這也讓他變得更加強(qiáng)大和實(shí)用。 還在用數(shù)據(jù)庫(kù)的like來(lái)實(shí)現(xiàn)產(chǎn)品的全文檢索嗎？拋棄她，用ElasticSearch吧~

ElasticSearch（下簡(jiǎn)稱ES）是基于Lucene的一個(gè)開源搜索引擎產(chǎn)品。Lucene是java編寫的一套開源文檔檢索的基礎(chǔ)庫(kù)，包括詞、文檔、域、倒排索引、段、相關(guān)性得分等基本功能，而ES則是使用了這些庫(kù)，搭建的一個(gè)可以直接拿來(lái)使用的搜索引擎產(chǎn)品。直觀地理解，Lucene提供汽車零部件，而ES直接賣車。


說(shuō)起ES的誕生，也是個(gè)很有意思的故事。ES的作者Shay Banon——“幾年前他還是一個(gè)待業(yè)工程師，跟隨自己的新婚妻子來(lái)到倫敦。妻子想在倫敦學(xué)習(xí)做一名廚師，而自己則想為妻子開發(fā)一個(gè)方便搜索菜譜的應(yīng)用，所以才接觸到Lucene。直接使用Lucene構(gòu)建搜索有很多問(wèn)題，包含大量重復(fù)性的工作，所以Shay便在Lucene的基礎(chǔ)上不斷地進(jìn)行抽象，讓Java程序嵌入搜索變得更容易，經(jīng)過(guò)一段時(shí)間的打磨便誕生了他的第一個(gè)開源作品Compass，中文即'指南針'的意思。之后，Shay找到了一份面對(duì)高性能分布式開發(fā)環(huán)境的新工作，在工作中他漸漸發(fā)現(xiàn)越來(lái)越需要一個(gè)易用的、高性能、實(shí)時(shí)、分布式搜索服務(wù)，于是他決定重寫Compass，將它從一個(gè)庫(kù)打造成了一個(gè)獨(dú)立的server，并將其改名為Elasticsearch?！?br>
引自（http://www.infoq.com/cn/news/2014/12/elasticsearch-birth-development）。


可見鼓搗起來(lái)的程序員是多么有愛，雖然據(jù)說(shuō)Shay Banon承諾給妻子的菜譜搜索還沒問(wèn)世......


本文大概地介紹了ES的原理，以及Wetest在使用ES中的一些經(jīng)驗(yàn)總結(jié)。因?yàn)镋S本身涉及的功能和知識(shí)點(diǎn)非常廣泛，所以這里重點(diǎn)挑出了實(shí)際項(xiàng)目中可能會(huì)用到，也可能會(huì)踩坑的一些關(guān)鍵點(diǎn)進(jìn)行了闡述。

重要概念

集群（Cluster）：ES是一個(gè)分布式的搜索引擎，一般由多臺(tái)物理機(jī)組成。這些物理機(jī)，通過(guò)配置一個(gè)相同的cluster name，互相發(fā)現(xiàn)，把自己組織成一個(gè)集群。


節(jié)點(diǎn)（Node)：同一個(gè)集群中的一個(gè) Elasticearch主機(jī)。


主分片（Primary shard）：索引（下文介紹）的一個(gè)物理子集。同一個(gè)索引在物理上可以切多個(gè)分片，分布到不同的節(jié)點(diǎn)上。分片的實(shí)現(xiàn)是Lucene 中的索引。

注意：ES中一個(gè)索引的分片個(gè)數(shù)是建立索引時(shí)就要指定的，建立后不可再改變。所以開始建一個(gè)索引時(shí)，就要預(yù)計(jì)數(shù)據(jù)規(guī)模，將分片的個(gè)數(shù)分配在一個(gè)合理的范圍。


副本分片（Replica shard）：每個(gè)主分片可以有一個(gè)或者多個(gè)副本，個(gè)數(shù)是用戶自己配置的。ES會(huì)盡量將同一索引的不同分片分布到不同的節(jié)點(diǎn)上，提高容錯(cuò)性。對(duì)一個(gè)索引，只要不是所有shards所在的機(jī)器都掛了，就還能用。主、副本、節(jié)點(diǎn)的概念如下圖：


索引（Index)：邏輯概念，一個(gè)可檢索的文檔對(duì)象的集合。類似與DB中的database概念。同一個(gè)集群中可建立多個(gè)索引。比如，生產(chǎn)環(huán)境常見的一種方法，對(duì)每個(gè)月產(chǎn)生的數(shù)據(jù)建索引，以保證單個(gè)索引的量級(jí)可控。索引->類型->文檔，ES中的文檔以這樣的邏輯關(guān)系組織了起來(lái)。


類型（Type）：索引的下一級(jí)概念，大概相當(dāng)于數(shù)據(jù)庫(kù)中的table。同一個(gè)索引里可以包含多個(gè) Type。 個(gè)人感覺在實(shí)際使用中type這一級(jí)常常用的不多，直接就在一個(gè)索引中建一個(gè)type，在這個(gè)type下去建立文檔集合和進(jìn)行搜索了。


文檔（Document)：即搜索引擎中的文檔概念，也是ES中一個(gè)可以被檢索的基本單位，相當(dāng)于數(shù)據(jù)庫(kù)中的row，一條記錄。


字段（Field）：相當(dāng)于數(shù)據(jù)庫(kù)中的column。ES中，每個(gè)文檔，其實(shí)是以json形式存儲(chǔ)的。而一個(gè)文檔可以被視為多個(gè)字段的集合。比如一篇文章，可能包括了主題、摘要、正文、作者、時(shí)間等信息，每個(gè)信息都是一個(gè)字段，最后被整合成一個(gè)json串，落地到磁盤。


映射（Mapping）：相當(dāng)于數(shù)據(jù)庫(kù)中的schema，用來(lái)約束字段的類型，不過(guò) Elasticsearch 的 mapping 可以不顯示地指定、自動(dòng)根據(jù)文檔數(shù)據(jù)創(chuàng)建。


Elasticsearch很友好地提供了RestFul的API，可以通過(guò)HTTP請(qǐng)求直接完成所有操作。比如下面官方的一個(gè)例子，往索引twitter添加文檔，type是tweet，文檔的id是1：


相應(yīng)地，根據(jù)user字段檢索文檔：

關(guān)鍵配置項(xiàng)

1、索引的shards個(gè)數(shù):
shards的個(gè)數(shù)，最好是和節(jié)點(diǎn)數(shù)相關(guān)的。理論上對(duì)同一個(gè)索引，單機(jī)上的shards個(gè)數(shù)最好不要超過(guò)兩個(gè)，這樣每個(gè)查詢盡可能并行。但因?yàn)镋S中shards的個(gè)數(shù)是確定了就沒辦法再調(diào)整的，所以如果考慮到數(shù)據(jù)會(huì)高速增長(zhǎng)，一開始分配多些也可以。另一個(gè)常見思路是按時(shí)間緯度（如月）去定義ES索引——因?yàn)榭梢詣?dòng)態(tài)調(diào)整新加的索引的shards個(gè)數(shù)。其他的一些情況，比如下面舉到的Wetest聚合的例子，因?yàn)樾枰獢?shù)據(jù)盡量地按照渠道切分開，所以定義了很多個(gè)shards（200個(gè)），但太多的shards通常是不推薦的，ES管理起來(lái)也有開銷。


2、heap內(nèi)存:
官方建議是可用內(nèi)存的一半，是通過(guò)啟動(dòng)ES的環(huán)境中，定義環(huán)境變量的方式完成的。如export ES_HEAP_SIZE=10g


3、cluster.name:
集群的邏輯名稱。只有cluster name相同的機(jī)器，才會(huì)在邏輯上組成一個(gè)集群。比如，內(nèi)網(wǎng)中有5臺(tái)ES機(jī)器的實(shí)例，是可以構(gòu)成幾個(gè)互不干擾的ES集群的。


4、discovery.zen.minimum_master_nodes:
這個(gè)是用于集群的分布式?jīng)Q策的最少master機(jī)器個(gè)數(shù)。和常見的分布式協(xié)調(diào)算法一樣，為了避免腦裂現(xiàn)象，建議超過(guò)一半的機(jī)器，n/2+1


5、discovery.zen.ping.unicast.hosts:
ES集群的機(jī)器列表。注意ES單點(diǎn)不用配置集群中的所有機(jī)器列表，像一個(gè)連通圖一樣，只要每臺(tái)機(jī)器配置了其他機(jī)器，而這些配置又是互相可以連接的，那ES最終就會(huì)發(fā)現(xiàn)所有機(jī)器，構(gòu)成集群。如['111.111.111.0','111.111.111.1','111.111.111.2']

mapping

mapping類似于數(shù)據(jù)庫(kù)里的表結(jié)構(gòu)，定義個(gè)mapping就意味著創(chuàng)建了一個(gè)索引。與數(shù)據(jù)庫(kù)不同的是，一個(gè)索引并不需要顯示地建立mapping，比如，上面那個(gè)在twitter索引插入文檔數(shù)據(jù)的例子，如果執(zhí)行的時(shí)候還沒有定義索引，ES便會(huì)根據(jù)文檔的字段和內(nèi)容，自動(dòng)創(chuàng)建索引和mapping。然而，這樣創(chuàng)建的索引字段，往往可能不是我們所需要的。所以，還是自己預(yù)先通過(guò)手動(dòng)定義mapping來(lái)創(chuàng)建索引比較好。下面是創(chuàng)建mapping的例子，這個(gè)例子在my_index這個(gè)目錄下，為user、blogpost這些type創(chuàng)建了mapping。其中properties下面是各種字段的定義，包括了string、數(shù)值、日期等類型的定義。


如圖中的紅框部分，這個(gè)例子中有兩個(gè)需要注意的地方：

1、user_id是string類型的，但它的index被定義為了“not_analzyed"，這個(gè)需要搞清其中的意義：通常，搜索引擎中全文檢索的功能簡(jiǎn)單說(shuō)是這樣實(shí)現(xiàn)的：對(duì)原始文檔進(jìn)行分詞后用這些詞去建立倒排索引，在線上檢索時(shí)，再將用戶的查詢?cè)~進(jìn)行分詞，用分詞結(jié)果去拉取多個(gè)倒排索引的拉鏈結(jié)果、歸并、相關(guān)性排序等，得到最終結(jié)果。但是，對(duì)于有些string類型的字段，其實(shí)并不想建倒排，就只想精確匹配，比如用戶的名字，只想查到name字段精確為“張三”的人，而不是分詞后得到的“張四”和“李三”兩個(gè)人，這個(gè)時(shí)候，就需要定義index類型字段。這個(gè)字段有no、analyzed、not_analyzed三種類型，no是壓根兒不給這字段建索引，analyzed是分析和按全文檢索的方式建，not_analyzed是完全匹配的關(guān)鍵詞查詢方式。


2、date類型，創(chuàng)建mapping時(shí)需要通過(guò)“format”指定錄入的多種可能時(shí)間格式。這樣創(chuàng)建文檔的時(shí)候，ES會(huì)根據(jù)輸入文檔的字段自動(dòng)去確定是哪一種。不過(guò)直觀地想象下，在創(chuàng)建文檔時(shí)，指定明確的時(shí)間格式，省去ES動(dòng)態(tài)判斷的開銷，應(yīng)該會(huì)提升些微小的性能。此外，要注意，epoch_second（秒單位時(shí)間戳）和epoch_millis（毫秒單位）盡量不要混用，如果非要混用也要在插入的時(shí)候明確指明是哪個(gè)。曾經(jīng)踩過(guò)坑，插入epoch_second的是秒級(jí)時(shí)間戳，但ES優(yōu)先認(rèn)為是毫秒，導(dǎo)致時(shí)間被縮小1000倍，最近的時(shí)間變成了1970年當(dāng)年的某個(gè)時(shí)間。


下圖列出了ES當(dāng)前版本中可以進(jìn)行mapping的數(shù)據(jù)類型、內(nèi)置的字段、mapping操作可以攜帶的參數(shù)。因?yàn)槠蜻@里就不詳細(xì)解釋了：


這里要詳細(xì)介紹的，是上圖中紅框標(biāo)出的，我們創(chuàng)建mapping時(shí)實(shí)際用到的比較關(guān)鍵的兩個(gè)內(nèi)置類型，和兩個(gè)mapping參數(shù)。這幾個(gè)都會(huì)直接影響最后索引訪問(wèn)的性能：

1）_source：es會(huì)把所有字段拼成一個(gè)原始的json落入磁盤，所以這個(gè)可以理解為全量原始數(shù)據(jù)，他不能用來(lái)索引，卻可以在需要的時(shí)候返回。注意盡量不要禁用，比如禁用后，用script去update就不支持了。


2）_all：一個(gè)“偽”字段，用來(lái)實(shí)現(xiàn)模糊的全文索引。可以這樣理解：在建索引的時(shí)候，把所有字段拼成一個(gè)字符串，然后對(duì)這個(gè)“大”字段進(jìn)行切詞，建倒排，然后這個(gè)字段就被丟棄了，沒有真正落入磁盤。當(dāng)全文檢索時(shí)，如果沒有指明查詢的域，比如標(biāo)題、正文（這種是很常見的），就從這個(gè)大的倒排中拉取文檔拉鏈。可以想象，一些標(biāo)記或值類型的字段，如日期、得分，這種在全文檢索時(shí)是沒意義的，就可以不包含在_all內(nèi)，而文本域，如title、doc，就包含在_all之中。這些都是在建mapping時(shí)可以、而且最好指定的。


3）doc_values：doc_values和下面的field_data都是在聚合（后面會(huì)介紹）、排序這些統(tǒng)計(jì)時(shí)用的參數(shù)，默認(rèn)都是開啟的。排序、聚合，這種在文檔全局進(jìn)行的工作，用倒排索引肯定不合適。所以，對(duì)not_analyzed（即不建倒排）的字段，doc_values用一種列模式的方式（可以參考hbase）來(lái)存儲(chǔ)文檔的正排，方便在文檔全局做統(tǒng)計(jì)。doc_values是存儲(chǔ)在磁盤的，如果你明確有些字段只是展示，不用于統(tǒng)計(jì)的話，可以把這個(gè)禁用掉。Doc_values一定不會(huì)對(duì)analyzed域建索引（都切詞了，想想也不合適，怎么建列索引嘛），而是用下面的field data。


4）field_data：對(duì)analyzed的文本域，比如正文，其實(shí)也會(huì)有統(tǒng)計(jì)的需求（比如ES也支持按一些關(guān)鍵詞對(duì)文檔進(jìn)行聚合統(tǒng)計(jì)，但這種任務(wù)常用的方法是通過(guò)離線工具，如hadoop或者單機(jī)的分析，做好了后推送到在線索引，直接在ES去算其實(shí)感覺有些奇怪）。雖然并不適合在搜索引擎中做，但你真的做了，es也會(huì)把這個(gè)數(shù)據(jù)動(dòng)態(tài)地load內(nèi)存的一個(gè)field data中進(jìn)行運(yùn)算。所以，想想就知道，這是個(gè)非常耗內(nèi)存的操作，很可能把jvm heap吃完了?。s默認(rèn)是只打開，但不load，只是在你需要進(jìn)行analyzed域的排序和聚合的時(shí)候，才去動(dòng)態(tài)load這個(gè)內(nèi)存（lazy的方式）。所以，盡量不要在查詢的時(shí)候去打開這個(gè)潘多拉魔盒，或者干脆就把這個(gè)選項(xiàng)關(guān)掉吧。

聚合

誰(shuí)說(shuō)搜索引擎只能用來(lái)搜索？ES不僅能搜索，還能在搜索的結(jié)果集合上直接進(jìn)行統(tǒng)計(jì)，很強(qiáng)大吧。ES目前穩(wěn)定的非實(shí)驗(yàn)階段聚合主要分兩種：Metrics Aggregation（指標(biāo)聚合）和Bucket Aggregation（桶聚合）。


指標(biāo)聚合主要指常規(guī)的集合數(shù)學(xué)統(tǒng)計(jì)類運(yùn)算，如官方guide的這個(gè)例子：找到交易的所有紅色的車，然后求它們的平均價(jià)格：


結(jié)果大概是這樣的：


神奇吧~指標(biāo)運(yùn)算還包括其他，如最大、最小、求和、個(gè)數(shù)、地理坐標(biāo)運(yùn)算等。然而我們今天要進(jìn)行實(shí)例講解的則主要是Bucket Aggregation，桶聚合。桶聚合是指把文檔，按照某個(gè)給定字段分成不同的組，然后在組內(nèi)進(jìn)行進(jìn)一步聚合運(yùn)算，并返回桶級(jí)的結(jié)果。比較直觀的理解，如：直方圖、分時(shí)間段統(tǒng)計(jì)等等。如下面這個(gè)例子，是桶聚合中的term聚合，即按照color這個(gè)字段，精確匹配后進(jìn)行分桶，然后桶內(nèi)還進(jìn)一步嵌套了平均價(jià)格聚合、和按制造商進(jìn)一步的分桶聚合。


統(tǒng)計(jì)的結(jié)果類似下面這樣，紅色的車共有4輛，平均價(jià)格是32500，并且又包含了3輛本田和1輛寶馬：


上面是簡(jiǎn)單的例子。在我們的WeTest輿情中，有論壇熱帖這樣一個(gè)功能，即，實(shí)時(shí)統(tǒng)計(jì)某個(gè)數(shù)據(jù)源中（如百度貼吧），某個(gè)論壇里（如王者榮耀吧），一段時(shí)間內(nèi)（如3個(gè)月），回復(fù)數(shù)最多的TopN個(gè)帖子。


這個(gè)功能現(xiàn)在在線上的實(shí)現(xiàn)方法就不詳細(xì)介紹了，大致是從數(shù)據(jù)庫(kù)和Hbase中掃描對(duì)應(yīng)的數(shù)據(jù)，維持一個(gè)堆，獲取出TOP N的思路。一方面是稍微有些耗時(shí)，另一方面是請(qǐng)求量很大時(shí)可能對(duì)DB和Hbase的訪問(wèn)帶來(lái)壓力，所以也想找一種備選的方案，我們想到了用ES。


為了用ES的桶聚合，我們首先設(shè)計(jì)如何存儲(chǔ)文檔（即所有用戶評(píng)論）的方案。由于數(shù)據(jù)量非常大（十億級(jí)），所以我們首先想到了把文檔按時(shí)間分成不同的索引（如按月），然后在指定月份（如3個(gè)月）的索引上，聚合出評(píng)論最多的Top帖子。然而這樣是有問(wèn)題的：當(dāng)在多個(gè)ES索引上聚合時(shí)，ES不會(huì)把所有索引的結(jié)果放在一起聚合TopN，而是單獨(dú)在每個(gè)索引求得TopN后，再放在一起聚合。這是個(gè)使用時(shí)要注意的小坑。這樣導(dǎo)致的結(jié)果是，直接在多個(gè)索引上聚合出的TopN，并不是真正的TopN（比如3個(gè)月中，每個(gè)月都是不是Top 1，但三個(gè)月加起來(lái)就是Top了 1。局部最優(yōu)不等于全局最優(yōu)）。


所以，從時(shí)間上切分，這條路基本被堵死了。那只能從空間上切分了（您問(wèn)能不能不切分？十億級(jí)的數(shù)據(jù)量，上百個(gè)GB，不切分的話，乖乖，每次都要從這幾百GB的文件里找東西，想想也知道有多慢了...）。從空間切分，同樣需要考慮兩個(gè)問(wèn)題：1）如何將數(shù)據(jù)hash到shards。2）切分多少個(gè)shards。對(duì)于第一個(gè)問(wèn)題，因?yàn)槲覀兊木酆辖y(tǒng)計(jì)是在每個(gè)渠道（可以理解為論壇）下的，不會(huì)跨渠道，所以，按照渠道ID進(jìn)行shards分配，把相同論壇的數(shù)據(jù)hash到一個(gè)shard即可。這樣，每次請(qǐng)求某個(gè)渠道的聚合結(jié)果，把請(qǐng)求按渠道ID routing到對(duì)應(yīng)的shard去運(yùn)算。對(duì)于第二個(gè)問(wèn)題，要看具體的規(guī)模了。我們的數(shù)據(jù)量有上百G，數(shù)據(jù)源上千個(gè)，所以我們希望每個(gè)shard上的內(nèi)容盡量少，保證在單個(gè)shard上聚合的時(shí)候會(huì)更快，當(dāng)然shards個(gè)數(shù)又不能太多，否則會(huì)給ES引入非常大的管理開銷。綜合下來(lái)，我們選擇的shards個(gè)數(shù)是200個(gè)。


遺憾的是，ES只能根據(jù)你指定的key（論壇ID）去做hash后進(jìn)行路由，這就導(dǎo)致了不同的shards上數(shù)據(jù)不是完全平均的，最多的能超過(guò)10GB，最少的只有幾十MB。如果哪一天，ES如果開放自定義routing規(guī)則或者對(duì)shards數(shù)據(jù)進(jìn)行均衡的方法，那就好了。


ES經(jīng)常為人詬病的一個(gè)地方是建索引比較慢，10億數(shù)據(jù)的索引構(gòu)建時(shí)間要花幾天。這也容易理解，天下沒有免費(fèi)的午餐，讀寫的性能往往是互斥的，快速讀取和檢索意味著大量索引和輔助數(shù)據(jù)的預(yù)先建立，那寫入時(shí)勢(shì)必會(huì)慢。如何取舍，需要看實(shí)際的業(yè)務(wù)場(chǎng)景而定了。下面就是建好索引后，去聚合某論壇內(nèi)指定時(shí)間段內(nèi)Top帖子的接口調(diào)用方式。


然后，我們按連續(xù)統(tǒng)計(jì)最熱的TopN（N為不同的個(gè)數(shù)）個(gè)渠道內(nèi)的Top30熱帖結(jié)果的方式分別對(duì)ES和線上已有的服務(wù)進(jìn)行了測(cè)試：


上面的五個(gè)結(jié)果圖直觀地反應(yīng)了用現(xiàn)在Wetest輿情線上的常規(guī)統(tǒng)計(jì)方式和ES聚合統(tǒng)計(jì)的方式獲取結(jié)果的耗時(shí)。


從結(jié)果中，我們大概推斷出了ES統(tǒng)計(jì)聚合運(yùn)算的做法：先把所有符合過(guò)濾條件的數(shù)據(jù)全部檢索出來(lái)，然后在內(nèi)存中進(jìn)行排序和聚合運(yùn)算。也就是說(shuō)，符合條件的數(shù)據(jù)量級(jí)越大，聚合運(yùn)算越慢。本著這個(gè)原則，結(jié)果圖也就比較好理解了：

1）在連續(xù)對(duì)最熱的Top1000個(gè)渠道去進(jìn)行熱帖聚合時(shí)，ES的表現(xiàn)大部分都優(yōu)于現(xiàn)有實(shí)現(xiàn)。這是因?yàn)門op1000的渠道中，大部分渠道被分在了非常小的shards上，有的只有幾MB，數(shù)據(jù)量很小，在這樣的shards中聚合，是很快的。


2）時(shí)間緯度上，統(tǒng)計(jì)3個(gè)月的數(shù)據(jù)，ES大部分情況下都比現(xiàn)有方法慢，而1個(gè)月或1天的情況下，ES都要快。這是因?yàn)?個(gè)月的條件下，符合條件的數(shù)據(jù)量級(jí)增大（最大的一個(gè)話題下有3萬(wàn)跟帖），ES的運(yùn)算效率下降比較厲害。


3）從Top1000到Top10，ES的總時(shí)間逐漸變差于現(xiàn)有方法。這是因?yàn)椋臻g緯度上，Top10渠道符合條件的數(shù)據(jù)量級(jí)非常大，所以ES的運(yùn)算效率下降比較厲害。


做了這個(gè)實(shí)驗(yàn)后，ES在WeTest頭部數(shù)據(jù)源上的聚合速度并不比現(xiàn)在快，但在中部和長(zhǎng)尾上的效果更優(yōu)，這說(shuō)明ES的聚合受候選集數(shù)據(jù)量的影響非常大，所以是否切換這種方式也還沒最終決定。不過(guò)，這個(gè)實(shí)驗(yàn)證明了ES聚合的強(qiáng)大能力，至少，不用自己寫什么代碼，只通過(guò)接口調(diào)用就能把這樣海量數(shù)據(jù)的統(tǒng)計(jì)運(yùn)算完成了，還是很方便的一件事情，同時(shí)性能也不錯(cuò)。如果自行實(shí)現(xiàn)的統(tǒng)計(jì)運(yùn)算中會(huì)增大DB的壓力，那么通過(guò)ES聚合分離這部分請(qǐng)求，也是一個(gè)非常好的選擇。


WeTest產(chǎn)品輿情，一站式了解你的產(chǎn)品口碑和用戶喜好，體驗(yàn)請(qǐng)點(diǎn)擊：騰訊WeTest輿情

如喜歡本文歡迎收藏及分享，謝謝您的支持！

原文鏈接：http://wetest.qq.com/lab/view/300.html