關注留言點贊，帶你了解最流行的軟體開發知識與最新科技行業趨勢。
Apache Doris 2.0.0 中的反向索引以其 1/5 的存儲空間實作了比 Elasticsearch 快兩倍的日志查詢性能。
日志通常占據了公司資料資産的大部分。日志的示例包括業務日志（例如使用者活動日志）和伺服器、資料庫以及網絡或物聯網裝置的操作和維護日志。
日志是商業的守護天使。一方面，提供系統風險預警，幫助工程師快速定位故障根源。另一方面，如果按時間範圍縮小它們，您可能會發現一些有用的趨勢和模式，更不用說業務日志是使用者洞察力的基石。
但是，日志可能很少，因為：
- 他們瘋狂地湧入。每個系統事件或使用者點選都會生成一個日志。一家公司經常每天生産數百億個新日志。
- 它們很笨重。日志應該保留。在它們有用之前它們可能沒有用。是以一個公司可以積累PB級的日志資料，其中有很多很少被通路卻占用巨大存儲空間的日志資料。
- 它們必須能夠快速加載和查找。定位目标日志進行故障排除簡直就像大海撈針。人們渴望實時的日志寫入和日志查詢的實時響應。
現在您可以清楚地了解理想的日志處理系統是什麼樣的。它應該支援以下内容：
- 高吞吐量實時資料攝取：它應該能夠批量編寫部落格并立即顯示它們。
- 低成本存儲：它應該能夠存儲大量的日志而不需要花費太多的資源。
- 實時文本搜尋：它應該能夠快速搜尋文本。
常見解決方案：Elasticsearch 和 Grafana Loki
業界常見的日志處理方案有兩種，分别是Elasticsearch和Grafana Loki。
- 反向索引（Elasticsearch）：由于支援全文搜尋和高性能而廣受歡迎。缺點是實時寫入吞吐量低，索引建立資源消耗大。
- 輕量級索引/無索引（Grafana Loki）：它與反向索引相反，因為它具有高實時寫入吞吐量和低存儲成本但提供慢查詢。
反向索引簡介
Elasticsearch 在日志處理方面的一個突出優勢是在海量日志中快速搜尋關鍵字。這是由反向索引啟用的。
反向索引最初用于檢索文本中的單詞或短語。下圖說明了它是如何工作的：
在寫入資料時，系統将文本标記為術語，并将這些術語存儲在一個釋出清單中，該清單将術語映射到它們所在行的 ID。在文本查詢中，資料庫在posting list中找到關鍵字（term）對應的行ID，并根據行ID擷取目标行。通過這樣做，系統将不必周遊整個資料集，進而将查詢速度提高幾個數量級。
最新的 DZone Refcard
可觀察性成熟度模型
下載下傳備忘單
在Elasticsearch的反向索引中，快速檢索是以寫入速度、寫入吞吐量和存儲空間為代價的。為什麼？首先，tokenization、字典排序、反向索引建立都是CPU和記憶體密集型操作。其次，Elasticsearch 必須存儲原始資料，反向索引，以及存儲在列中的額外資料副本以用于查詢加速。那是三重備援。
但是沒有反向索引，比如Grafana Loki，查詢速度慢，影響使用者體驗，是日志分析工程師最大的痛點。
簡單地說，Elasticsearch 和 Grafana Loki 代表了高寫入吞吐量、低存儲成本和快速查詢性能之間的不同權衡。如果我告訴你有辦法擁有它們呢？我們在Apache Doris 2.0.0中引入了反向索引，并進一步優化，以其 1/5 的存儲空間實作了比 Elasticsearch 快兩倍的日志查詢性能。這兩個因素結合起來，這是一個好 10 倍的解決方案。
Apache Doris 中的反向索引
索引的實作方式一般有兩種：外部索引系統或者内置索引。
外部索引系統：您将外部索引系統連接配接到您的資料庫。在資料攝取中，資料被導入到兩個系統中。索引系統建立索引後，會删除自己内部的原始資料。當資料使用者輸入查詢時，索引系統提供相關資料的ID，然後資料庫根據ID查找目标資料。
建構外部索引系統更容易，對資料庫的幹擾更小，但它有一些惱人的缺陷：
- 需要将資料寫入兩個系統會導緻資料不一緻和存儲備援。
- 資料庫和索引系統的互動會帶來開銷，是以當目标資料很大時，跨兩個系統的查詢會很慢。
- 維護兩個系統很累。
在Apache Doris中，我們選擇了另一種方式。内置反向索引制作起來比較困難，但是一旦完成，速度更快，更人性化，維護起來也更省事。
在 Apache Doris 中，資料按以下格式排列。索引存儲在索引區域中：
我們以非侵入式的方式實作反向索引：
- Data ingestion and compaction : 當一個段檔案被寫入 Doris 時，一個反向索引檔案也會被寫入。索引檔案路徑由段ID和索引ID決定。段中的行對應索引中的文檔，RowID 和 DocID 也是如此。
- 查詢：如果where子句中包含反向索引的列，系統會在索引檔案中查找，傳回一個DocID清單，并将DocID清單轉換成RowID Bitmap。在 Apache Doris 的 RowID 過濾機制下，隻會讀取目标行。這就是加速查詢的方式。
這種非侵入性的方法将索引檔案與資料檔案分開，是以您可以對反向索引進行任何更改，而不必擔心影響資料檔案本身或其他索引。
反向索引的優化
一般優化
C++ 實作和向量化
與使用 Java 的 Elasticsearch 不同，Apache Doris 在其存儲子產品、查詢執行引擎和反向索引中實作了 C++。與 Java 相比，C++ 提供更好的性能，允許更容易的矢量化，并且不會産生 JVM GC 開銷。我們對 Apache Doris 中反向索引的每一步都進行了矢量化，例如标記化、索引建立和查詢。給大家提供一個視角，在反向索引中，Apache Doris 以每核 20MB/s 的速度寫入資料，是 Elasticsearch（5MB/s）的四倍。
列式存儲和壓縮
Apache Lucene 為 Elasticsearch 中的反向索引奠定了基礎。由于 Lucene 本身是為支援檔案存儲而建構的，是以它以面向行的格式存儲資料。
在Apache Doris中，不同列的反向索引互相隔離，反向索引檔案采用列式存儲，便于向量化和資料壓縮。
Apache Doris 通過使用 Zstandard 壓縮，實作了5:1到10:1 的壓縮比，壓縮速度更快，空間占用比 GZIP 壓縮減少 50%。
數字/日期時間列的 BKD 樹
Apache Doris 為數字和日期時間列實作 BKD 樹。這不僅提高了範圍查詢的性能，而且比将這些列轉換為固定長度的字元串更節省空間。它的其他好處包括：
- 高效的範圍查詢：能夠在numeric和datetime列中快速定位到目标資料範圍。
- 更少的存儲空間：聚合和壓縮相鄰的資料塊以降低存儲成本。
- 支援多元資料：BKD 樹具有可擴充性和适應多元資料類型的能力，例如 GEO 點和範圍。
除了 BKD 樹，我們還進一步優化了對數字和日期時間列的查詢。
- 針對低基數場景的優化：我們對低基數場景的壓縮算法進行了微調，是以對大量倒排清單進行解壓反序列化會消耗更少的CPU資源。
- 預取：對于命中率高的場景，我們采用預取。如果命中率超過某個門檻值，Doris 将跳過索引過程并開始資料過濾。
針對 OLAP 的定制優化
通常，日志分析是一種簡單的查詢，不需要進階功能（例如 Apache Lucene 中的相關性評分）。日志處理工具的主要功能是快速查詢和低存儲成本。是以，在Apache Doris中，我們精簡了反向索引結構來滿足OLAP資料庫的需求。
- 在資料攝取中，我們防止多個線程将資料寫入同一個索引，進而避免鎖争用帶來的開銷。
- 我們丢棄正向索引檔案和規範檔案以清理存儲空間并減少 I/O 開銷。
- 我們簡化了相關性評分和排名的計算邏輯，以進一步減少開銷并提高性能。
鑒于日志是按時間範圍分區的，曆史日志的通路頻率較低，我們計劃在 Apache Doris 的未來版本中提供更細粒度和更靈活的索引管理：
- 為指定資料分區建立反向索引：為過去7天的日志等建立索引。
- 删除指定資料分區的反向索引：删除一個多月前日志的索引等（以清理索引空間）。
對标
我們針對 Elasticsearch 和 ClickHouse 在公開可用的資料集上測試了 Apache Doris。
為了公平比較，我們確定測試條件的一緻性，包括基準測試工具、資料集和硬體。
Apache Doris 與 Elasticsearch
- 基準測試工具：ES Rally，Elasticsearch官方測試工具
- 資料集：1998 年世界杯 HTTP 伺服器日志（ES Rally 中的獨立資料集）
- 資料大小（壓縮前）：32G，2.47 億行，每行 134 位元組（平均）
- 查詢：11個查詢，包括關鍵詞搜尋、範圍查詢、聚合、排名；每個查詢連續執行 100 次。
- 環境：3×16C 64G雲虛拟機
Apache Doris 的結果：
- 寫入速度：550MB/s， 是Elasticsearch的4.2倍
- 壓縮比：10:1
- 存儲使用：Elasticsearch 的 20%
- 響應時間：Elasticsearch 的 43%
Apache Doris 與 ClickHouse
由于 ClickHouse 在 v23.1 中推出了反向索引作為實驗特性，我們使用 ClickHouse部落格中描述的相同資料集和 SQL 對 Apache Doris 進行了測試， 并比較了兩者在相同測試資源、案例和工具下的性能。
- 資料：6.7G，2873萬行，Hacker News資料集，Parquet格式
- 查詢：3 個關鍵字搜尋，計算關鍵字“ClickHouse”、“OLAP”或“OLTP”以及“avx”和“sve”的出現次數。
- 環境：1×16C 64G雲虛拟機
結果：Apache Doris在三個查詢中分别比 ClickHouse 快4.7 倍、18.5 倍和 12 倍。
用法和示例
- 資料集：來自 Hacker News 的一百萬條評論記錄
第一步：在建表時為資料表指定反向索引。
參數：
- INDEX idx_comment( comment)：為“評論”列建立一個名為“idx_comment”評論的索引
- USING INVERTED：為表指定反向索引
- PROPERTIES("parser" = "english"): 指定分詞語言為英文
CREATE TABLE hackernews_1m
(
`id` BIGINT,
`deleted` TINYINT,
`type` String,
`author` String,
`timestamp` DateTimeV2,
`comment` String,
`dead` TINYINT,
`parent` BIGINT,
`poll` BIGINT,
`children` Array<BIGINT>,
`url` String,
`score` INT,
`title` String,
`parts` Array<INT>,
`descendants` INT,
INDEX idx_comment (`comment`) USING INVERTED PROPERTIES("parser" = "english") COMMENT 'inverted index for comment'
)
DUPLICATE KEY(`id`)
DISTRIBUTED BY HASH(`id`) BUCKETS 10
PROPERTIES ("replication_num" = "1");
（注：可以通過ADD INDEX idx_comment ON hackernews_1m(comment) USING INVERTED PROPERTIES("parser" = "english")為已有表添加索引，與智能索引和二級索引不同，反向索引的建立隻涉及到comment列的讀取，速度會快很多。）
第二步：用 檢索評論欄中的單詞“OLAP”和“OLTP” MATCH_ALL。這裡的響應時間是與like. （性能差距随着資料量的增加而擴大。）
mysql> SELECT count() FROM hackernews_1m WHERE comment LIKE '%OLAP%' AND comment LIKE '%OLTP%';
+---------+
| count() |
+---------+
| 15 |
+---------+
1 row in set (0.13 sec)
mysql> SELECT count() FROM hackernews_1m WHERE comment MATCH_ALL 'OLAP OLTP';
+---------+
| count() |
+---------+
| 15 |
+---------+
1 row in set (0.01 sec)
更多功能介紹和使用指南，參見文檔：反向索引
總結
總之，Apache Doris 比 Elasticsearch 高出 10 倍的成本效益的原因在于其針對反向索引的 OLAP 定制優化，支援列存儲引擎、大規模并行處理架構、向量化查詢引擎和基于成本的優化器阿帕奇多麗絲。
盡管我們對自己的反向索引解決方案感到自豪，但我們知道自行釋出的基準可能會引起争議，是以我們願意接受任何第三方測試人員的回報，并了解Apache Doris在實際案例中的工作方式。