关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。

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 中，数据按以下格式排列。索引存储在索引区域中：

我们以非侵入式的方式实现倒排索引：

1. Data ingestion and compaction : 当一个段文件被写入 Doris 时，一个倒排索引文件也会被写入。索引文件路径由段ID和索引ID决定。段中的行对应索引中的文档，RowID 和 DocID 也是如此。
2. 查询：如果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 树。这不仅提高了范围查询的性能，而且比将这些列转换为固定长度的字符串更节省空间。它的其他好处包括：

1. 高效的范围查询：能够在numeric和datetime列中快速定位到目标数据范围。
2. 更少的存储空间：聚合和压缩相邻的数据块以降低存储成本。
3. 支持多维数据：BKD 树具有可扩展性和适应多维数据类型的能力，例如 GEO 点和范围。

除了 BKD 树，我们还进一步优化了对数字和日期时间列的查询。

1. 针对低基数场景的优化：我们对低基数场景的压缩算法进行了微调，因此对大量倒排列表进行解压反序列化会消耗更少的CPU资源。
2. 预取：对于命中率高的场景，我们采用预取。如果命中率超过某个阈值，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,
`url` String,
`score` INT,
`title` String,
`parts` Array,
`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在实际案例中的工作方式。