作者：morningchen，騰訊 TEG 后臺(tái)開發(fā)工程師

Elasticsearch（ ES ）是一款功能強(qiáng)大的開源分布式實(shí)時(shí)搜索引擎，在日志分析（主要應(yīng)用場(chǎng)景）、企業(yè)級(jí)搜索、時(shí)序分析等領(lǐng)域有廣泛應(yīng)用，幾乎是各大公司搜索分析引擎的開源首選方案。

Tencent ES 是內(nèi)核級(jí)深度優(yōu)化的 ES 分支，持續(xù)地進(jìn)行高可用、高性能、低成本等全方位優(yōu)化，已支撐的單集群規(guī)模達(dá)到千級(jí)節(jié)點(diǎn)、萬億級(jí)吞吐。Tencent ES 已在公司內(nèi)部開源，同時(shí)也積極貢獻(xiàn)開源社區(qū)，截止目前已向社區(qū)提交 PR 25+。騰訊聯(lián)合 Elastic 官方在騰訊云上提供了內(nèi)核增強(qiáng)版 ES 云服務(wù)，支撐公司內(nèi)部云、外部云、專有云達(dá) 60PB+ 的數(shù)據(jù)存儲(chǔ)，服務(wù) 蘑菇街、知乎、B 站、鳳凰網(wǎng)等業(yè)內(nèi)頭部客戶。

本文主要介紹 Tencent ES 的主要優(yōu)化點(diǎn)之一：零拷貝 內(nèi)存 Off Heap，提升內(nèi)存使用效率，降低存儲(chǔ)成本。最終達(dá)到，在讀寫性能與源生邏輯一致的前提下，堆內(nèi)存使用率降低 80%，單節(jié)點(diǎn)存儲(chǔ)量從 5TB 提升至 50TB 的效果。

問題：日志分析場(chǎng)景數(shù)據(jù)量大，ES 內(nèi)存瓶頸導(dǎo)致存儲(chǔ)成本較高

上節(jié)提到，日志分析是 ES 的主要應(yīng)用場(chǎng)景（占比 60%），而日志數(shù)據(jù)的特點(diǎn)顯著：

• 數(shù)據(jù)量大，成本是主要訴求：我們大批線上大客戶，數(shù)據(jù)量在幾百 TB 甚至 PB 級(jí)，單集群占用幾百臺(tái)機(jī)器。如此規(guī)模的數(shù)據(jù)量，帶來了較高的成本，甚至有些客戶吐槽，日志的存儲(chǔ)成本已超越產(chǎn)品自身的成本。

• 數(shù)據(jù)訪問冷熱特性明顯：如下圖所示，日志訪問近多遠(yuǎn)少，歷史極少訪問卻占用大量成本。

分析：成本瓶頸在哪里：堆內(nèi)存使用率過高

我們對(duì)線上售賣的集群做硬件成本分析后，發(fā)現(xiàn)成本主要在磁盤和內(nèi)存。為了降低磁盤成本，我們采取冷熱分離、Rollup、備份歸檔、數(shù)據(jù)裁剪等多種方式降成本。在冷熱分離的集群，我們通過大容量的冷存儲(chǔ)機(jī)型，來存儲(chǔ)歷史數(shù)據(jù)，使得磁盤成本下降 60% 左右。

問題也隨之而來：如上圖所示，大容量的冷機(jī)型，存在磁盤使用率過低的問題（ 40 % 以下），原因是堆內(nèi)存使用率過高了（ 70 % 左右），制約磁盤使用率無法提升。（其中單節(jié)點(diǎn)磁盤使用率 40%，約 13TB 左右，這已經(jīng)是 Tencent ES 優(yōu)化后的效果，源生只能支持到 5 TB 左右）所以，為了提升低成本的冷機(jī)型磁盤使用率，同時(shí)也為了降低內(nèi)存成本，我們需要降低 ES 的堆內(nèi)存使用率。

堆內(nèi)存使用率為什么會(huì)高？

ES 是通過 JAVA 語言編寫的，在介紹如何降低堆內(nèi)存使用率之前，先了解下 JAVA 的堆內(nèi)存：

• 堆內(nèi)存就是由 JVM （JAVA 虛擬機(jī)）管理的內(nèi)存。建立在堆內(nèi)存中的對(duì)象有生命周期管理機(jī)制，由垃圾回收機(jī)時(shí)自動(dòng)回收過期對(duì)象占用的內(nèi)存。

• 堆外內(nèi)存是由用戶程序管理的內(nèi)存，堆外內(nèi)存中的對(duì)象過期時(shí)，需要由用戶代碼顯示釋放。

1. 運(yùn)營(yíng)側(cè)調(diào)整裝箱策略能否解決問題？

了解了 JAVA 堆內(nèi)存后，我們看，能否通過調(diào)整運(yùn)營(yíng)策略來提升堆內(nèi)存容量呢？

• 堆內(nèi)存分配大一點(diǎn)行不行？超過 32GB，指針壓縮失效，內(nèi)存浪費(fèi)， 50GB 堆內(nèi)存性能與 31GB 接近且垃圾回收壓力大，也影響性能；

• 多節(jié)點(diǎn)部署提高堆內(nèi)存總量是否可行？多節(jié)點(diǎn)部署，占用機(jī)器量更大，用戶成本上升大客戶節(jié)點(diǎn)數(shù)過多（ 幾百個(gè) ），集群元數(shù)據(jù)管理瓶頸，可用性下降 反向推動(dòng)云上用戶拆分集群，阻力很大。

所以，簡(jiǎn)單的運(yùn)營(yíng)側(cè)策略調(diào)整無法解決堆內(nèi)存使用率過高的問題。那么我們就需要確認(rèn) ES 的堆內(nèi)存是被什么數(shù)據(jù)占用了，能否優(yōu)化。

2. 堆內(nèi)存被什么數(shù)據(jù)占用了？

我們對(duì)線上集群的堆內(nèi)存分布情況做統(tǒng)計(jì)分析后，發(fā)現(xiàn)絕大部分堆內(nèi)存主要被 FST（ Finite State Transducer ）占用了：

• FST 內(nèi)存占用量占分堆內(nèi)存總量的 50% ~ 70%

• FST 與 磁盤數(shù)據(jù)量成正比：10TB 磁盤數(shù)據(jù)量，其對(duì)應(yīng)的 FST 內(nèi)存占用量在 10GB ~ 15GB 左右。

因此，我們的目標(biāo)就是就是通過內(nèi)核層的優(yōu)化，降低 FST 的堆內(nèi)存占用量。

方案：降低 FST 堆內(nèi)存占用量

什么是 FST ？

在介紹具體的方案前，先來了解下 FST 到底是什么。

如上圖所示，ES 底層存儲(chǔ)采用 Lucene（搜索引擎），寫入時(shí)會(huì)根據(jù)原始數(shù)據(jù)的內(nèi)容，分詞，然后生成倒排索引。查詢時(shí)，先通過查詢倒排索引找到數(shù)據(jù)地址（DocID）），再讀取原始數(shù)據(jù)（行存數(shù)據(jù)、列存數(shù)據(jù)）。但由于 Lucene 會(huì)為原始數(shù)據(jù)中的每個(gè)詞都生成倒排索引，數(shù)據(jù)量較大。所以倒排索引對(duì)應(yīng)的倒排表被存放在磁盤上。這樣如果每次查詢都直接讀取磁盤上的倒排表，再查詢目標(biāo)關(guān)鍵詞，會(huì)有很多次磁盤 IO，嚴(yán)重影響查詢性能。為了解磁盤 IO 問題，Lucene 引入排索引的二級(jí)索引 FST [Finite State Transducer] 。原理上可以理解為前綴樹，加速查詢。

其原理如下：

將原本的分詞表，拆分成多個(gè) Block ，每個(gè) Block 會(huì)包含 25 ~ 48 個(gè)詞（Term）。圖中做了簡(jiǎn)單示意，Allen 和 After 組成一個(gè) Block 。

將每個(gè) Block 中所有詞的公共前綴抽取出來，如 Allen 和 After 的公共前綴是 A 。

將各個(gè) Block 的公共前綴，按照類似前綴樹的邏輯組合成 FST，其葉子節(jié)點(diǎn)攜帶對(duì)應(yīng) Block 的首地址 。（實(shí)際 FST 結(jié)構(gòu)更為復(fù)雜，前綴后綴都有壓縮，來降低內(nèi)存占用量）

為了加速查詢，FST 永駐堆內(nèi)內(nèi)存，無法被 GC 回收。

用戶查詢時(shí)，先通過關(guān)鍵詞（Term）查詢內(nèi)存中的 FST ，找到該 Term 對(duì)應(yīng)的 Block 首地址。再讀磁盤上的分詞表，將該 Block 加載到內(nèi)存，遍歷該 Block ，查找到目標(biāo) Term 對(duì)應(yīng)的 DocID。再按照一定的排序規(guī)則，生成 DocID 的優(yōu)先級(jí)隊(duì)列，再按該隊(duì)列的順序讀取磁盤中的原始數(shù)據(jù)（行存或列存）。

由此可知，FST 常駐堆內(nèi)內(nèi)存，無法被 GC 回收 ， 長(zhǎng)期占用 50% ~ 70% 的堆內(nèi)存 ！

解決方案

既然 FST 是常駐堆內(nèi)內(nèi)存，導(dǎo)致堆內(nèi)存使用率過高，那么解決問題的思路有兩種：

降低 FST 在堆內(nèi)的內(nèi)存使用量

將 FST 從堆內(nèi)存（OnHeap，有 32GB 容量限制）移到堆外內(nèi)存（OffHeap）。因?yàn)槎淹鈨?nèi)存無容量上限，可通過擴(kuò)充機(jī)器內(nèi)存來提升容量。（堆外內(nèi)存容量限制近似為 物理內(nèi)存 - JAVA 堆內(nèi)存）自然也就有了相應(yīng)方案：

解決方案一：降低 FST 在堆內(nèi)的內(nèi)存使用量

在 Tencent ES 成立前期，我們采用過這種方案。具體的做法是，將 FST 對(duì)應(yīng)的 Block 大小，從 25 ~ 48，放大一倍至 49 ~ 96 。這樣，在 關(guān)鍵詞 Term 數(shù)相同的情況下，Block 數(shù)量降低了一倍，對(duì)應(yīng)的 FST 內(nèi)存理論上也會(huì)下降一倍。

• 優(yōu)點(diǎn)：我們實(shí)測(cè)發(fā)現(xiàn)，這種方案下，FST 的堆內(nèi)存占用量下降了 40% 左右。

• 缺點(diǎn)：(1)由于 Block 內(nèi)的 Term 數(shù)變多了，那么每次遍歷 Block 查找目標(biāo) Term 時(shí)，需要從磁盤讀取的數(shù)據(jù)量更大了，因此也帶來了明顯的查詢性能損耗，約 20% 。(2)該方案只是讓 FST 占用的內(nèi)存下降了一半，仍無法控制 FST 占用的內(nèi)存總量。不同場(chǎng)景下，FST 數(shù)據(jù)量大小差異也很大，在全文檢索的字段較多時(shí)，仍然存在 FST 內(nèi)存過高的問題。

由此我們可以看出，簡(jiǎn)單的降低 FST 的堆內(nèi)存使用量，并不是一個(gè)普適性的方案，需要更為通用、徹底限制住 FST 總大小的方案。

解決方案二：將 FST 從堆內(nèi)存（OnHeap）移到堆外內(nèi)存（OffHeap）

將 FST 從堆內(nèi)存（OnHeap）移到堆外內(nèi)存（OffHeap），幾乎可以完全釋放 FST 在堆內(nèi)存占據(jù)的使用空間，這也是 JAVA 實(shí)踐方向上一個(gè)普遍使用的方案。對(duì)于 JAVA 的堆內(nèi)存不足，將部分內(nèi)存移到堆外內(nèi)存（OffHeap）的問題，ES 社區(qū) 和 其他 JAVA 系產(chǎn)品都有相應(yīng)的解決方案。

ES 社區(qū)方案：該方案是將 FST 從堆內(nèi)存中剔除， 直接交由 MMAP 管理。FST 在磁盤上也是有對(duì)應(yīng)的持久化文件的，Lucene 的 .tip 文件，該方案每次查詢時(shí)直接通過 MMap 讀取 .tip 文件，通過文件系統(tǒng)緩存 FST 數(shù)據(jù)。

• 優(yōu)點(diǎn)：這種方實(shí)現(xiàn)簡(jiǎn)單，代碼改動(dòng)量小

• 缺點(diǎn)：(1)我們?cè)缙谝苍囉眠^這種方式實(shí)現(xiàn)，但是由于 MMAP 屬于 page cache 可能被系統(tǒng)回收掉。而且 ES 的大查詢也會(huì)使用大量的系統(tǒng)緩存導(dǎo)致 FST 占用的內(nèi)存被沖掉，瞬間產(chǎn)生較多的讀盤操作，從而帶來性能的 N 倍損耗，容易產(chǎn)生查詢毛刺。特別是在 SATA 盤上，嚴(yán)重時(shí)查詢時(shí)延有 10 倍的毛刺。(2)Lucene 8.x 、ES 7.x 后才支持該功能，存量的 6.x 用戶無法使用。

HBase 方案 HBase 的方案是，在堆外搭建一個(gè) Cache，將其一部分堆內(nèi)存（Bucket Cache，Data Block 緩存）移到堆外，釋放堆內(nèi)內(nèi)存。

• 優(yōu)點(diǎn)：數(shù)據(jù)緩存放在堆外，釋放大量堆內(nèi)內(nèi)存

• 缺點(diǎn)：(1)淘汰策略完全依賴 LRU 策略，(2)只是把數(shù)據(jù)緩存放置在堆外，索引的緩存還在堆內(nèi)

Tencent ES 方案 我們的方案總體上接近 HBase 的方案，相比之下：

• 優(yōu)點(diǎn)：(1)相比于 ES 社區(qū)方案，我們堆外的 Cache 保證 FST 的內(nèi)存空間不受系統(tǒng)影響。(2)相比于 HBase 方案，我們實(shí)現(xiàn)了更精準(zhǔn)的數(shù)據(jù)淘汰策略，提高了內(nèi)存使用率。也通過多級(jí) Cache 解決性能問題，所以我們敢于把索引放置在堆外。

實(shí)現(xiàn)：全鏈路 0 拷貝 FST OffHeap Cache

下面通過將由淺入深地向大家介紹我們實(shí)現(xiàn) FST OffHeap 的過程，及其中碰見的問題和解決方案。

總體架構(gòu)

在實(shí)現(xiàn) OffHeap 方案的初期，我們的架構(gòu)如上圖所示。先來看下源生邏輯是怎樣訪問 FST 的：

• 數(shù)據(jù)寫入：ES 的一次 Refresh / Merge 動(dòng)作，會(huì)生成一個(gè)新的 Lucene Segment，相應(yīng)的在磁盤上生成該 Segment 對(duì)應(yīng)的各種數(shù)據(jù)文件。其中 .tip 文件里面存儲(chǔ)的就是該 Segment 各個(gè)字段的 FST 信息。在生成 .tip 文件后，Lucene 也會(huì)將每個(gè)字段（ Field ）的 FST 數(shù)據(jù)解析后，拷貝至該 Field 在 OnHeap 內(nèi)存中的對(duì)象里，作為一個(gè)成員變量永駐內(nèi)存，直到該 Segment 被刪除 （ Index 被刪除、Segment Merge 時(shí) ）。

• 數(shù)據(jù)查詢：查詢時(shí)，直接訪問 OnHeap 的 FST 。

再來看下優(yōu)化后的 Tencent ES 是怎樣訪問 FST 的：

• 數(shù)據(jù)寫入：在 OffHeap 內(nèi)存放置一個(gè) LRU Cache，在生成新的 Segment 時(shí)，不再將 .tip 中的 FST 數(shù)據(jù)拷貝至 OffHeap LRU Cache。將其對(duì)應(yīng)的 Key 放置在 OnHeap 的 Field 中，不再將 FST 拷貝至 OnHeap 的 Field 中。這樣就把 FST 從 OnHeap 移到了 OffHeap。

• 數(shù)據(jù)查詢：查詢時(shí)，通過 OnHeap Field 中保存的 Key，去 OffHeap LRU Cache 中查詢 FST 數(shù)據(jù)，將其拷貝至 OnHeap 后，做查詢操作。若 Cache Miss ，則從磁盤的 .tip 文件中的相應(yīng)位置讀取該 Field 對(duì)應(yīng)的 FST 做查詢，同時(shí)將其放置到 OffHeap LRU Cache 中。

將兩種方案做個(gè)對(duì)比，如下表所示：

那么可以總結(jié)出 Tencent ES 優(yōu)化后的 FST 訪問邏輯的優(yōu)勢(shì)和劣勢(shì)：

• 優(yōu)勢(shì)：在 OnHeap 我們用 100B 左右的 Key 置換 MB 級(jí)別的 FST，大大降低的內(nèi)存占用量，使得單節(jié)點(diǎn)最大支持的磁盤數(shù)據(jù)量有了 5 倍以上的提升。

• 劣勢(shì)：FST 在每次查詢時(shí)都要從 OffHeap LRU Cache 拷貝至 OnHeap，相比于源生邏輯直接訪問 OnHeap 的 FST ，讀寫都多了拷貝的動(dòng)作，造成高并發(fā)讀寫時(shí)有 20%+ 的性能損耗。

所以，我們要對(duì) OffHeap LRU Cache 的讀寫路徑做優(yōu)化，減少 Copy 次數(shù)，提升讀寫性能。具體的實(shí)現(xiàn)方案是全鏈路零拷貝 OffHeap FST 訪問邏輯。

全鏈路零拷貝 OffHeap FST 訪問邏輯

ES 源生邏輯訪問 FST 只支持堆內(nèi)的操作，怎樣做到讓它能直接訪問堆外的數(shù)據(jù)呢？

為此，我們做了兩方面優(yōu)化：

• OffHeap LRU Cache：改造讀數(shù)據(jù)邏輯，Cache 只返回?cái)?shù)據(jù)地址，封裝為一個(gè) Buffer，堆內(nèi)只存數(shù)據(jù)地址，這樣就把 FST 的訪問從先拷貝至 OnHeap 再訪問優(yōu)化為直讀 OffHeap 內(nèi)存。

• ES：重構(gòu) FST 讀寫邏輯，實(shí)現(xiàn) FST 訪問直讀 OffHeap 內(nèi)存：

• FST 抽象為一個(gè) FST Buffer，對(duì)外提供 FST 形式的各種訪問接口。內(nèi)部實(shí)現(xiàn)按 FST 的數(shù)據(jù)結(jié)構(gòu)讀取 OffHeap Buffer 的邏輯，作為訪問 OffHeap FST 的代理。

• 將 ES 訪問 FST 的所有鏈路全部改造為 FST Buffer 接口的形式，優(yōu)化 FST 的讀寫路徑如下所示：

經(jīng)過上述優(yōu)化，把 FST 的數(shù)據(jù)訪問由 1 次 Copy 優(yōu)化為 0 Copy，實(shí)現(xiàn)了全鏈路零拷貝 OffHeap FST 訪問邏輯。同時(shí)也將 FST 的數(shù)據(jù)寫入從 2 次 Copy 優(yōu)化為 1 次 Copy。讀寫性能損耗從 20%+ 下降至 7%。

雖然這樣性能影響已經(jīng)比較小了，但我們還是想挑戰(zhàn)下自己，能否將性能優(yōu)化到極致呢？

多級(jí) Cache 將性能優(yōu)化到極致

要進(jìn)一步優(yōu)化性能，需要搞清楚一個(gè)問題：7% 的性能損耗在哪里？Perf 分析后發(fā)現(xiàn)，Hot 堆棧是 OffHeap Cache 計(jì)算 Hash、校驗(yàn) Key 等邏輯。為什么會(huì)有頻繁讀 Cache 的操作呢？我們分析 Lucene 的源碼發(fā)現(xiàn)，在高并發(fā)讀寫時(shí)，一次讀寫入上千條數(shù)據(jù)，則會(huì)有讀 Cache 上千次。例如，一個(gè) bulk update 寫入 3000 條數(shù)據(jù)，3 分片，每個(gè)分片大概有 1000 條數(shù)據(jù) update 操作，那么就有 1000 次讀 Cache 的邏輯。而這 1000 次讀 Cache，基本上是讀的同一個(gè) Key （_id 對(duì)應(yīng)的 Key），能否做到讓這 1000 次查詢的 Key，稍微緩存一會(huì)，防止那么多次讀 Cache 的操作呢？

我們的優(yōu)化方案是：OnHeap + OffHeap 的兩級(jí) Cache 架構(gòu)，降低 OffHeap Cache 訪問頻率。 而堆內(nèi)的 Cache 一定要輕量，最少的占用 OnHeap 內(nèi)存，否則就違背了我們要將 FST 從 OnHeap 移出去的初衷。所以，我們最終選用堆內(nèi)的弱引用機(jī)制（ WeakRefrence ）來緩存 OffHeap FST 的指針，作為 OnHeap 的輕量級(jí) Cache，利用 JVM 的 GC 自動(dòng)釋放無效的弱引用，同時(shí)堆外內(nèi)存。

相比于直接設(shè)置一個(gè) OnHeap Cache，弱引用有占用內(nèi)存小，避免拷貝等優(yōu)勢(shì)。

這樣我們?cè)L問 FST 的邏輯，會(huì)先查詢堆內(nèi)的各個(gè)查詢共享的 WeakRefrence，當(dāng)其已經(jīng)被釋放時(shí)，才會(huì)訪問 OffHeap Cache。這樣就大大降低了 OffHeap Cache 的訪問頻率。

這里的挑戰(zhàn)是，兩級(jí) Cache，key 的關(guān)聯(lián)釋放問題。JVM GC 時(shí)會(huì)銷毀 WeakRefrence 對(duì)應(yīng)的 OnHeap 對(duì)象，但 Java 無析構(gòu)函數(shù)，無法自動(dòng)釋放堆外指針。而我們期望，在堆內(nèi)的 WeakRefrence 釋放時(shí)，同時(shí)釋放堆外指針，從而對(duì) OffHeap Cache 的 Key 的引用計(jì)數(shù)減一，使其可以根據(jù) LRU 規(guī)則自動(dòng)回收無效的 FST 數(shù)據(jù)。

深入分析 JAVA 垃圾回收、弱引用機(jī)制后，發(fā)現(xiàn)可以通過注冊(cè)一個(gè) WeakRefrence Queue，在 WeakRefrence 釋放前，可以捕獲到它。進(jìn)而改造 WeakRefrence 的數(shù)據(jù)結(jié)構(gòu)，使其在被捕獲后，對(duì) OffHeap Cahe 的 Key 引用計(jì)數(shù)減一，然后才被回收。

經(jīng)過上述 OnHeap WeakRefrence + OffHeap LRU Cache 兩級(jí) Cache 架構(gòu)的優(yōu)化后，高并發(fā)讀寫性能基本與源生邏輯持平。

其他優(yōu)化點(diǎn)

除了上述的性能優(yōu)化外，Tencent ES 的 FST OffHeap 還做了一些其他優(yōu)化：

• 精準(zhǔn)控制 Cache 淘汰策略，內(nèi)存高效使用：

• LSM Tree 底層文件合并過程，及時(shí)淘汰無效數(shù)據(jù)

• 字段粒度 Cache 控制：有去重需求：主鍵（_id ）寫入 Cache，提升寫入性能 無去重需求：主鍵（_id ）不寫入 Cache，降低內(nèi)存成本【20%-40%】

• CAS 并發(fā)控制：解決 Cache Miss 后，并發(fā)讀文件的 IO 放大問題

• 不停服動(dòng)態(tài)調(diào)整 Cache 大小：用戶可根據(jù)業(yè)務(wù)情況，在不停服的情況下隨時(shí)調(diào)整 Cache 大小

• 不停服動(dòng)態(tài)開關(guān) OffHeap Cache ：

• 用戶按需開關(guān) OffHeap Cache 功能

• 存量集群上線部署兼容性

優(yōu)化效果

最后來看下我們層層優(yōu)化后，最終的效果：

壓測(cè)效果

通過 ES 官方 Bench 工具 ES Rally 壓測(cè)，結(jié)果如下：

線上效果

根據(jù)線上集群的實(shí)際運(yùn)行效果看，當(dāng)開啟 OffHeap 功能后，集群整體平均 JVM 的內(nèi)存使用率從 70%+ 下降 至 30% 左右。

Tencent ES 將持續(xù)地進(jìn)行高可用、高性能、低成本等全方位優(yōu)化：可用性方面，將提升 ES 的故障自愈能力、故障自動(dòng)分析診斷，達(dá)到零接觸運(yùn)維的目標(biāo)；高性能方面，將進(jìn)一步提升 ES 的海量數(shù)據(jù)實(shí)時(shí)分析能力；低成本方面，將提供存儲(chǔ)與計(jì)算分離的能力，基于騰訊自研的共享文件系統(tǒng) CFS，進(jìn)一步縮減成本。

最后，歡迎各位對(duì) ES 內(nèi)核技術(shù)有興趣的同學(xué)掃描下方的二維碼與我們展開交流，同時(shí)也歡迎大家在騰訊云體驗(yàn) CES 云服務(wù)。

總結(jié)

以上是生活随笔為你收集整理的腾讯万亿级 Elasticsearch 内存效率提升技术解密的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。