開源搜索引擎排名第一，Elasticsearch是如何作到的？

1、引言

 

隨着移動互聯網、物聯網、雲計算等信息技術蓬勃發展，數據量呈爆炸式增加。現在咱們能夠輕易得從海量數據裏找到想要的信息，離不開搜索引擎技術的幫助。

​

做爲開源搜索引擎領域排名第一的 Elasticsearch，可以讓咱們無需深刻了解背後複雜的信息檢索原理，就可實現基本的全文檢索功能，在數據量達到十億，百億規模仍然能夠秒級返回檢索結果。

 

對於系統容災、數據安全性、可擴展性、可維護性等用戶關注的實際問題，在Elasticsearch 上也能獲得有效解決。

 

2、Elasticsearch 介紹

 

Elasticsearch（ES）是一個基於 Lucene 構建的開源分佈式搜索分析引擎，能夠近實時的索引、檢索數據。具有高可靠、易使用、社區活躍等特色，在全文檢索、日誌分析、監控分析等場景具備普遍應用。

 

因爲高可擴展性，集羣可擴展至百節點規模，處理PB級數據。經過簡單的 RESTful API 便可實現寫入、查詢、集羣管理等操做。

 

除了檢索，還提供豐富的統計分析功能。以及官方功能擴展包 XPack 知足其餘需求，如數據加密、告警、機器學習等。

 

另外，可經過自定義插件，如 COS 備份、QQ 分詞等知足特定功能需求。

 

1. Elasticsearch 架構與原理

 

 

基本概念 ：

 

• Cluster「集羣」：由部署在多個機器的ES節點組成，以處理較大數據集和實現高可用；

• Node「節點」：機器上的ES進程，可配置不一樣類型的節點；

• Master Node「主節點」：用於集羣選主。由其中一個節點擔任主節點，負責集羣元數據管理，如索引建立，節點離開加入集羣等；

• Data Node「數據節點」：負責索引數據存儲；

• Index「索引」：索引數據的邏輯集合，可類比關係型數據的DataBase；

• Shard「分片」：索引數據子集，經過將分片分配至集羣不一樣節點，實現數據橫向擴展。以解決單個節點CPU、內存、磁盤處理能力不足的狀況；

• Primary Shard「主分片」：數據分片採用主從模式，由分片接收索引操做；

• Replica Shard「副本分片」：主分片的拷貝，以提升查詢吞吐量和實現數據高可靠。主分片異常時，其中一個副本分片會自動提高爲新的主分片。

 

爲了便於你們理解ES裏的數據模型，將它與關係型數據庫 MySQL 作類比：

 

 

從上面架構圖能夠看出，ES 架構很是簡潔。內置自動發現實現 Zen discovery，當一個節點啓動後，經過聯繫集羣成員列表便可加入集羣。

 

由其中一個節點擔任主節點，用於集羣元數據管理，維護分片在節點間的分配關係。當新節點加入集羣后，Master 節點會自動遷移部分分片至新節點，均衡集羣負載。

 

 

分佈式集羣不免有節點故障。主節點會按期探測集羣其餘節點存活狀態，當節點故障後，會將節點移出集羣，並自動在其餘節點上恢復故障節點上的分片。

 

主分片故障時會提高其中一個副本分片爲主分片。其餘節點也會探活主節點，當主節點故障後，會觸發內置的類 Raft 協議選主，並經過設置最少候選主節點數，避免集羣腦裂。

 

 

除了集羣管理，索引數據讀寫也是咱們關心的重要部分。ES 採用 peer-to-peer 架構，每一個節點保存全量分片路由信息，也就是每一個節點都可以接收用戶讀寫。

 

如發送寫入請求至節點 1，寫入請求默認經過文檔 ID 的 Hash 值肯定寫入到哪一個主分片，這裏假設寫入到分片 0。

 

寫完主分片 P0，並行轉發寫入請求至副本分片 R0 所在節點，當副本分片所在節點確認寫入成功後返回客戶端報告寫入成功，保障數據安全性。而且寫入前，會確保 quorum 數量的副本數，避免網絡分區致使寫入數據不一致。

 

 

查詢採用分佈式搜索，如請求發給節點3後，請求會轉發至索引的主分片或副本分片所在節點。

 

固然若是寫入、查詢均帶有路由字段信息。請求只會發送給部分分片，避免全量分片掃描。這些節點完成查詢後將結果返回給請求節點，由請求節點匯聚各個節點的結果返回給客戶端。

 

 

2. Lucene原理

   

介紹完 ES 集羣基本原理，下面簡單介紹下ES的底層存儲引擎 Lucene。

 

首先 Lucene 是一款高性能的信息檢索庫，提供索引和檢索基本功能。ES 在此基礎上解決可靠性、分佈式集羣管理等問題最終造成產品化的全文檢索系統。

Lucene 解決的核心問題即是全文檢索。與傳統的檢索方式不一樣，全文檢索避免在查詢時進行所有內容掃描。

 

好比數據寫入後，首先會對寫入的文檔字段內容分詞，造成詞典表和與它關聯的倒排表。查詢時由關鍵詞分詞結果直接匹配詞典表內容，並獲取關聯的文檔列表，快速獲取結果集。並經過排序規則，優先展現匹配度高的文檔。

 

 

Lucene 爲了加快索引速度，採用了 LSM Tree 結構，先把索引數據緩存在內存。當內存空間佔用較高或到達必定時間後，內存中的數據會寫入磁盤造成一個數據段文件（segment）。段文件內包含詞典、倒排表、字段數據等等多個文件。

 

 

爲了兼容寫入性能和數據安全性，如避免內存緩衝區裏的數據由於機器故障丟失。ES 在寫內存的同時也會寫事物日誌 Translog。內存裏的數據會按期生成新的段文件，寫入開銷更低的文件系統緩存便可打開和讀取實現近實時搜索。

 

 

3、Elasticsearch 應用場景

 

ES的典型使用場景有日誌分析、時序分析、全文檢索等。

 

1. 日誌實時分析場景

 

日誌是互聯網行業基礎普遍的數據形式。典型日誌有用來定位業務問題的運營日誌，如慢日誌、異常日誌；用來分析用戶行爲的業務日誌，如用戶的點擊、訪問日誌；以及安全行爲分析的審計日誌等。

 

Elastic 生態提供了完整的日誌解決方案。經過簡單部署，便可搭建一個完整的日誌實時分析服務。ES 生態完美的解決了日誌實時分析場景需求，這也是近幾年 ES 快速發展的一個重要緣由。

 

日誌從產生到可訪問通常在 10s 級，相比於傳統大數據解決方案的幾十分鐘、小時級時效性很是高。

 

ES底層支持倒排索引、列存儲等數據結構，使得在日誌場景能夠利用ES很是靈活的搜索分析能力。經過ES交互式分析能力，即便在萬億級日誌的狀況下，日誌搜索響應時間也是秒級。

 

日誌處理的基本流程包含：日誌採集 -> 數據清洗 -> 存儲 -> 可視化分析。Elastic Stack經過完整的日誌解決方案，幫助用戶完成對日誌處理全鏈路管理。

 

 

其中：

 

• 日誌採集：經過輕量級日誌採集組件FileBeat實時讀取業務日誌文件，發送數據至下游組件如 Logstash。

• 文本解析：利用正則解析等機制，將日誌文本數據轉換成結構化數據。可以使用獨立的Logstash 服務或 Elasticsearch 內置的輕量級數據處理模塊 Ingest Pipeline，完成數據清洗和轉換。

• 數據存儲：經過 Elasticsearch 搜索分析平臺進行數據持久存儲，提供全文搜索和分析能力。

• 可視化分析：經過功能豐富的圖形界面，便可對日誌數據進行搜索分析，如可視化組件 Kibana。

 

 

2. 時序分析場景

 

時序數據是按時間順序記錄設備、系統狀態變化的數據。典型的時序數據有傳統的服務器監控指標數據、應用系統性能監控數據、智能硬件、工業物聯網傳感器數據等。

 

早在2017年咱們也基於ES進行了時序分析場景的探索。時序分析場景具備高併發寫入、低查詢時延、多維分析的特色。

 

因爲ES具備集羣擴展、批量寫入、讀寫帶路由、數據分片等能力，目前已實現線上單集羣最大規模達到 600+節點、1000w/s 的寫入吞吐、單條曲線或單個時間線的查詢延時可控制在 10ms。

 

ES提供靈活、多維度的統計分析能力，實現查看監控按照地域、業務模塊等靈活的進行統計分析。另外，ES支持列存儲、高壓縮比、副本數按需調整等能力，可實現較低存儲成本。最後時序數據也可經過Kibana組件輕鬆實現可視化。

 

 

3. 搜索服務場景

 

搜索服務典型場景有像京東、拼多多、蘑菇街中的商品搜索；應用商店中的應用APP搜索；論壇、在線文檔等站內搜索。

 

這類場景用戶關注高性能、低延遲、高可靠、搜索質量等。如單個服務最大需達到 10w+ QPS，請求平均響應時間在 20ms之內，查詢毛刺低於 100ms，高可用如搜索場景一般要求 4 個 9 的可用性，支持單機房故障容災等。

 

目前雲上 Elasticsearch 服務已支持多可用區容災，故障分鐘級恢復能力。經過 ES 高效倒排索引，以及自定義打分、排序能力與豐富的分詞插件，實現全文檢索需求。在開源全文檢索領域，ES 在 DB-Engines 搜索引擎類別持續多年排名第一。

 

 

4、騰訊 Elasticserch 服務

   

騰訊內外部均有大量的日誌實時分析、時序數據分析、全文檢索需求場景。

 

目前咱們已聯合 Elastic 公司在騰訊雲上提供了內核加強版 ES 雲服務，簡稱CES，其中內核加強包括 Xpack 商業套件和內核優化。

 

在服務公司內部以及公有云客戶過程當中，也遇到了較多問題和挑戰，好比超大規模集羣，千萬級數據寫入，以及雲上用戶豐富的使用場景等。

 

下文將介紹咱們在內核層面，從可用性，性能，成本等方面進行的優化措施。

 

1. 可用性優化

 

   

可用性 問題表如今三個方面：

 

（1）ES 內核系統健壯性不足 

 

這也是分佈式系統共性難題。例如異常查詢、壓力過載集羣容易出現雪崩。集羣可擴展性不足，好比集羣分片數超10w會出現明顯的元數據管理瓶頸。以及集羣擴容、節點異常後加回集羣，存在節點、多硬盤之間數據不均問題。

 

（2）容災方案欠缺

 

需保障機房網絡故障時可快速恢復服務，天然災害下防止數據丟失，誤操做後快速恢復數據等可靠性、數據安全性問題。

 

（3）系統缺陷

 

另外也包括在運營過程當中發現的一些 ES 系統缺陷 ，好比說 Master 節點堵塞、分佈式死鎖、滾動重啓緩慢等。

 

 

針對上面的問題，在系統健壯性方面，咱們經過服務限流，容忍機器網絡故障、異常查詢等致使的服務不穩定問題。

 

經過優化集羣元數據管理邏輯，提高集羣擴展能力一個數量級，支持千級節點集羣、百萬級分片數。集羣均衡方面，經過優化節點、多硬盤間的分片均衡，保證大規模集羣的壓力均衡。

 

容災方案 方面，咱們經過擴展 ES 的插件機制實現數據備份和回檔，可把 ES 的數據備份到 COS，保障數據安全性；經過管控系統建設支持跨可用區容災，用戶能夠按需部署多個可用區，以容忍單機房故障。採用垃圾桶機制，保證用戶在欠費、誤操做等場景下，集羣數據可快速恢復。

 

系統缺陷方面，咱們修復了滾動重啓、Master 阻塞、分佈式死鎖等一系列 Bug。其中滾動重啓優化，可加速節點重啓速度 5+倍。Master 堵塞問題，咱們在 ES 6.x 版本和官方一塊兒作了優化。

 

2. 性能優化

 

性能問題，好比以日誌、監控爲表明的時序場景，對寫入性能要求很是高，寫入併發可達 1000w/s。然而咱們發如今帶主鍵寫入時，ES 性能會衰減 1+倍。

 

壓測場景下發現CPU 存在沒法充分利用的狀況。一般搜索服務對查詢性要求很是高，通常要求 20w QPS, 平均響應時間小於 20ms，而且需儘可能避免 GC、以及執行計劃不優等形成的查詢毛刺問題。

 

  

爲了解決這些問題。寫入方面，針對主鍵去重場景，咱們經過利用段文件上記錄的最大最小值進行查詢裁剪，加速主鍵去重的過程，寫入性能提高 45%，具體可參考 Lucene-8980[1]。

 

對於壓測場景下 CPU 不能充分利用的問題，經過優化 ES 刷新 Translog 時鎖粒度，避免資源搶佔，提高性能提高 20%，具體可參考ES-45765 /47790[2]。咱們也正在嘗試經過向量化執行優化寫入性能，經過減小分支跳轉、指令 Miss，預期寫入性能可提高 1 倍。

 

查詢方面，咱們經過優化段文件合併策略，對於非活躍段文件會自動觸發合併，收斂段文件數以下降資源開銷，提高查詢性能。

 

根據每一個段文件上記錄的最大最小值進行查詢剪枝，提高查詢性能 40%。經過 CBO 策略，避免緩存較大開銷的 Cache 操做致使產生 10+倍的查詢毛刺，具體可參考Lucene-9002[3]。

 

另外還包括優化 Composite 聚合中的性能問題，實現真正的翻頁操做，以及優化帶排序場景的聚合使得性能提高3-7倍。此外，咱們也在嘗試經過一些新硬件來優化性能，好比說英特爾的 AEP、Optane、QAT 等。

 

3. 成本優化

 

 

成本方面主要體如今以日誌、監控爲表明的時序場景對機器資源的消耗。結合線上典型的日誌、時序業務統計數據發現，硬盤、內存、計算資源的成本比例接近 8:4:1。

 

能夠得出硬盤、內存是主要矛盾，其次是計算成本。而這類時序類場景有很明顯的訪問特性，也就是數據具備冷熱特性。

 

時序數據訪問具備近多遠少的特色，好比近 7 天數據的訪問量佔比可達到 95%以上，而歷史數據訪問較少，而且一般都是訪問統計類信息。

 

 

硬盤成本方面，因爲數據具備明顯的冷熱特性，咱們採用冷熱分離架構，使用混合存儲的方案來平衡成本和性能。

 

因爲歷史數據一般只是訪問統計信息，咱們採用預計算 Rollup 換取存儲和查詢性能，相似物化視圖。對於徹底不使用歷史數據，也能夠備份到更廉價的存儲系統如 COS。其餘一些優化方式包括多盤策略兼容數據吞吐與數據容災，以及經過生命週期管理等按期刪除過時數據等。

 

內存成本 方面，咱們發現特別是大存儲機型，存儲資源才用了 20% 內存已不足。爲了解決內存不足問題，咱們採用 Off-Heap 技術，來提高堆內內存利用率，下降 GC 開銷，而且提高單個節點管理磁盤的能力。

 

將內存佔比較大的 FST 移到堆外管理，經過堆內存放堆外對象地址，避免堆內外數據拷貝。經過 Java 弱引用機制實現堆外對象內存回收，進一步提高內存使用率。

 

實現 32GB 堆內內存可管理 50 TB 左右磁盤空間，較原生版本有 10 倍提高，而且性能持平，而 GC 優點提高明顯。

除了內核層面的優化，在平臺層經過管控平臺，支持雲上服務資源管理、實例實例管理等實現服務託管。方便快捷進行實例建立和規格調整。

 

經過運維支撐平臺中的監控系統、運維工具等保障服務質量。並經過正在建設的智能診斷平臺發現服務潛在問題，實現了對內外部提供穩定可靠的 ES 服務。

 

 

騰訊內部，咱們主導了 ES 產品開源協同，發現潛在問題，共同優化完善 ES，避免不一樣的團隊重複踩坑。

 

同時咱們也將優秀的方案積極貢獻給社區，和官方及社區的 ES 愛好者們共同推進 ES 的發展。以騰訊 ES 內核研發爲表明的團隊，截至目前咱們共提交了 60 多個 PR，其中有 70% 被合併，公司內 ES 開源協同 PMC 成員共有 6 位 ES/Lucene 社區 contributor。

 

5、結語

 

 

Elasticsearch 在騰訊內外部普遍應用於日誌實時分析、時序數據分析、全文檢索等場景。

 

目前單集羣規模達到千級節點、萬億級吞吐。經過內核加強版 ES 爲你們提供高可靠，低成本，高性能的搜索分析服務。後續咱們仍需在可用性，性能和成本等方面持續優化 ES。

 

好比集羣可擴展性不足問題，經過優化集羣擴展性支持百萬級分片秒級建立 index。ES 的存儲成本問題，目前正在研發存儲與計算分離方案，進一步縮減成本，提高性能。以及存在使用和維護成本高的問題，後續經過多級分區、智能診斷等提高ES的自動化和故障自愈能力，下降用戶使用和維護成本。

 

將來，也會近一步探索 ES 在多維分析領域的其餘可能性。持續在大數據領域提供更有價值的搜索分析服務。

 

參考資料：

[1] Lucene-8980：

https://github.com/apache/lucene-solr/pull/884

[2] ES-45765 /47790:

https://github.com/elastic/elasticsearch/pull/45765

[3] Lucene-9002:

https://github.com/apache/lucene-solr/pull/940

看騰訊技術，學雲計算知識，就來雲+社區