Elasticsearch 是一款开源的分布式检索引擎，广泛应用于日志分析、全文搜索和数据监控等领域。凭借其强大的实时搜索能力和灵活的查询语言，在市场上获得了广泛认可。然而，在过去两年，我们注意到一个趋势，很多 Elasticsearch 用户倾向于采用 Apache Doris 替代 Elasticsearch。
尽管 Apache Doris 和 Elasticsearch 在表面上看似不同，但它们的应用场景却有很大的重叠。例如，Apache Doris 适用于在线高并发报表、用户画像、湖仓一体、日志与可观测性、安全分析等领域；Elasticsearch 作为一个搜索引擎在日志与可观测性等分析场景也被广泛使用。
本文将从技术选型的视角，全方位深度解析 Apache Doris 与 Elasticsearch 的差异，包括以下几点：
- 开源开放：开源和开放的程度决定了用户是否会被供应商锁定。
- 系统架构：系统架构决定了系统的部署模式和依赖的软硬要求。
- 实时写入：系统部署好之后，用户首要关注的是数据写入的方式及其效率。
- 实时存储：数据写入后采用何种数据模型存储，以及存储成本的考量至关重要。
- 实时查询：数据的写入和存储最终目的是提供查询，丰富的查询能力和高效的查询性能是用户通过数据库实现业务价值的关键。
1. 深入对比
1.1 开放性
产品的开放性影响了用户的选择，大多数用户倾向于选择更加开放的产品或项目。
Apache Doris 是 Apache 软件基金会的开源项目，采用 Apache Licence 2.0。该协议允许任何人和组织免费使用、修改和分发，只需保留许可证声明，可用于开源或商业产品。
Elasticsearch 的开源协议经历了多次变更。最初采用 Apache Licence 2.0，但自 2021 年 7.1.11 版本起转向 Elastic License 和 SSPL，旨在限制第三方商业使用以保护 Elastic 公司的利益。到 2024 年，Elastic 公司宣布 "Elasticsearch 再次开源"，新增 AGPL 协议，放宽商业使用限制。
开源协议的不同和变化本质上由项目的运营方式决定。Apache Doris 遵循"Apache Way"运营，保持开放性和中立性，因此保持 Apache Licence 2.0 不变。而 Elasticsearch 由 Elastic 公司管理，许可证可随需调整。
1.2 系统架构
系统架构决定了用户的部署方式，以及所需的软硬件资源。Apache Doris 支持多种部署模型，且在 3.0 版本后支持存算分离和存算一体两种架构，用户可根据需求灵活选择。Elasticsearch 只支持存算一体的部署模式，在资源弹性、负载隔离、存储分层方面有明显劣势。
1.3 实时写入
系统部署完成后，下一步是数据写入。Doris 和 Elasticsearch 在数据写入上存在显著差异，主要体现在写入方式和性能两个方面。
1.3.1 写入方式
数据写入通常有两种方式：推（Push）模式和拉（Pull）模式。在推模式下，外部系统通过 API 将数据写入数据库；而在拉模式下，数据库主动从外部数据源（如 Kafka）拉取数据并存储。
Elasticsearch 仅支持推模式，提供 HTTP API。如果要将 Kafka 中的数据写入 Elasticsearch，需要借助外部工具如 Logstash，后者负责从 Kafka 读取数据并推送到 Elasticsearch。
Doris 则同时支持推和拉两种模式。它提供 HTTP API 和 JDBC API 进行推写，同时支持内置的 Routine Load 从 Kafka 拉取数据，以及通过 Multi-Catalog 从对象存储、HDFS 和其他数据库同步数据到 Doris 。此外，Doris 还支持 Elasticsearch 生态中的 Logstash 和 Beats ，通过 Doris Output Plugin、Logstash 、Beats 可以将数据写入 Doris。
此外，Doris 提供了一种特殊的批量写入事务机制，既保证事务性又实现高吞吐。应用在写入一批数据时设置唯一标签，Doris 能识别重复写入，结合应用层的失败重试，可以在不依赖主键去重的情况下确保数据写入不丢不重，同时实现很高的写入吞吐。
1.3.2 写入性能
Elasticsearch 写入慢、CPU 消耗高是普遍存在的问题。这主要源于两方面：一是 Elasticsearch 及其底层的 Lucene 采用 Java 实现，向量化技术尚不成熟；二是多个副本需分别构建索引，从而导致 CPU 资源的多次消耗。
作为实时数仓，Doris 支持高吞吐的实时写入和更新。以下是使用 Elasticsearch 官方性能基准测试工具 httplogs 的对比结果，在相同测试资源和参数下 ，Doris 的写入吞吐量是 Elasticsearch 的 3 倍。
在创建相同倒排索引的前提下，Doris 提供了远超 Elasticsearch 的写入吞吐，这得益于多项优化：
- 采用 C++ 实现，运行效率高于 Elasticsearch 及其底层 Java。
- 全链路向量化执行引擎充分利用 CPU SIMD 指令，加速数据写入和倒排索引构建，列式存储和索引便于向量化优化。
- 针对实时分析场景优化倒排索引，去掉不必要的正排和 norm 存储结构，更加轻量高效。
- 仅需在一个副本中构建索引，其他副本通过拷贝避免重复的 CPU 消耗。
- 优化后台合并（compaction）策略，减少写放大，避免额外的 CPU 和 IO 资源消耗。
1.4 实时存储
1.4.1 存储空间
作为实时数仓，Doris 采用典型的关系模型，存储层次从高到低依次为 Catalog、Database、Table 和 Column。每个表由一个或多个列组成，每列具有独特的数据类型，并可创建索引。
Doris 默认采用列式存储，同一列的数据存储在连续的物理文件上，这不仅提高了压缩比，还在分析场景下能高效读取所需数据。此外，Doris 还支持可选的行存，以加速明细点查。
相比之下，Elasticsearch 的数据存储在 Lucene 中，采用文档模型。其 Index 相当于数据库的 Table，Index Mapping 类似于 Table Schema，Field 相当于 Column，并具有自己的类型和索引。Elasticsearch 默认使用行存（_source字段），每个 Field 都创建倒排索引，同时支持可选的列式存储（Docvalue）。对于 Elasticsearch 来说或，行存是查询原始明细数据的必要条件。
由于上述存储模型，Elasticsearch 通常需要存储行存、列存和倒排索引三份数据，而行存的压缩率较低，导致存储空间和成本高昂，这是它的另一痛点。
根据上一章节的 httplogs 对比测试，在创建相同倒排索引的前提下，Elasticsearch 占用 19.4GB，而 Doris 仅占 3.2GB，存储空间降低了 83%，意味着存储成本不到 Elasticsearch 的 1/5。 这一显著优化得益于 Doris 对存储空间的深入优化，例如：
- 采用紧凑的列式存储，提高了相似数据的压缩率。
- 实现 ZSTD 压缩算法，其压缩率高于常用的 GZIP 和 LZ5。
- 针对分析场景简化倒排索引，去掉行存以节省大量存储空间。
1.4.2 数据模型
Elasticsearch 和 Doris 都支持三种常用的数据模型：明细模型、主键模型和聚合模型，但对后两者的支持程度差异较大。
主键模型：
在 Elasticsearch 中，特殊的 _id字段类似于数据库的主键，用于唯一标识文档（相当于数据库的一行），并允许覆盖和更新。然而，它存在诸多限制：
- 不能用于聚合查询和排序
- 字段长度不能超过 512 字节
- 该字段是独立的，无法指定多个字段作为联合主键，用户需将多个字段拼接后写入
_id字段，且仍需遵循 512 字节的限制。
相比之下，Doris 的主键模型符合常规数据库标准，允许用户指定一个或多个字段作为唯一主键，并没有特别限制。
聚合模型：
Elasticsearch 早期通过商业化的 x-pack 插件提供 Rollup 功能，允许用户创建 Rollup Job，基于 Base Index 配置 Rollup Index 的维度、指标字段和聚合间隔。然而，x-pack Rollup 有一些局限：
- Rollup Job 是后台执行的，导致 Rollup Index 的数据与 Base Index 不同步。
- 查询需专门使用 Rollup 查询，用户必须手动指定 Rollup Index。
由于这些限制，从 8.1.1.0 版本开始，Elasticsearch 不再推荐使用 Rollup，而推荐新的 Downsampling功能。使用 Downsampling 时不需指定单独的 Index，查询更为简单，但也存在一些限制：
- 仅适用于时序数据，使用时间作为维度，其他数据（如报表）无法使用。
- Downsampling Index 会替换原始 Index，聚合数据与原始数据不能共存。
- 原始 Index 需在只读状态下才能进行 Downsampling，正在写入的数据无法进行聚合采样。
Doris 作为擅长聚合分析的实时数仓，在在线报表分析场景中提供了强大的聚合能力，主要通过以下两种灵活机制实现：
- 聚合物化视图或 Rollup：在基础表上创建聚合物化视图，数据写入基础表的同时，聚合视图也会更新。通过多表写入事务，确保基础表和聚合视图的原子同步更新。用户查询基础表时，查询优化器会自动改写为利用物化视图加速查询。
- 聚合表：在数据写入时直接进行聚合，只存储聚合后的数据，而不存储原始数据，从而显著降低存储空间。
通过上述机制，Doris 提供了强大的聚合分析加速能力：
- 不限制数据类型：用户只需定义聚合的维度和指标，适用于时序数据和业务报表等场景。
- 灵活存储原始数据：聚合表不存储原始数据，而聚合物化视图则可以选择存储。
- 实时更新：数据可更新，并保证更新的实时性和原子性。
- 透明的查询体验：用户无需关注底层的物化视图，直接执行聚合查询即可，系统会自动加速查询。
- 丰富的聚合能力 ：支持常用的 min、max、count、sum、avg 等聚合操作，还包括复杂的
bitmap_union，用于精确去重等场景。
1.4.3 Flexible Schema
在许多实时在线场景中，随着业务的发展，用户需要在不中断服务的情况下修改数据 Schema，例如新增或删除字段和索引。因此，Flexible Schema 的支持程度直接影响线上业务的可用性。
以下表格对比了 Doris 和 Elasticsearch 对 Flexible Schema 的支持情况：
1.4.3 Flexible Schema
在许多实时在线场景中，随着业务的发展，用户需要在不中断服务的情况下修改数据 Schema，例如新增或删除字段和索引。因此，Flexible Schema 的支持程度直接影响线上业务的可用性。以下表格对比了 Doris 和 Elasticsearch 对 Flexible Schema 的支持情况：
Elasticsearch 通过 Dynamic Mapping 支持一定程度的 Flexible Schema。当用户将 JSON 数据写入时，如果包含新字段，Dynamic Mapping 会自动在 Index Mapping 中添加对应字段。然而，Elasticsearch 不允许删除已有字段，用户只能创建新 Index，并通过 Reindex 操作将旧 Index 的数据迁移到新 Index，这一过程既耗时又消耗资源。
此外，Elasticsearch 不支持在现有字段上增加索引。例如，如果一个 Index 有 100 个字段，最初只为 10 个字段设置索引，后续想为其他字段添加索引时，用户必须通过耗时的 Reindex 操作实现。因此，为避免后续无法添加索引，用户常常在初始阶段为所有字段创建索引，这会导致写入性能下降和存储空间增加。Elasticsearch 还不允许用户修改字段或 Index 的名称，Reindex 后必须使用新名称，这对上层业务不友好。
相比之下，Doris 支持各种常见的 Schema Change 操作，包括修改字段和表名、增删字段和索引。新增索引对新写入的数据立即生效，而历史数据可以通过手动后台增量异步构建，且不影响正常的写入和查询。这种灵活的在线 schema change 使得业务发展不受现有数据库 Schema 的限制。
1.5 实时查询
数据的写入和存储最终是为了支持查询，而查询的功能和性能是实现业务价值的关键。接下来，我们将从查询的易用性、功能和性能方面对比 Doris 和 Elasticsearch。
1.5.1 查询易用性
Doris 提供了简单易用的标准 SQL 查询接口，并与 MySQL 协议兼容，用户可以通过 MySQL 的 CLI、JDBC 和 ODBC 直接访问 Doris。这种兼容性为用户带来了极大便利：许多数据分析师和工程师对 MySQL 已经非常熟悉，而 MySQL 也构建了庞大成熟的数据库生态，许多工具（如 BI、ETL 和可观测性工具）都支持 MySQL 接口，因此可以轻松访问 Doris。
Doris 选择与 MySQL 兼容，因为 MySQL 是最流行的 OLTP 数据库，而 Doris 致力于成为最流行的 OLAP 数据库。这种统一接口方便用户在 OLTP 和 OLAP 之间切换。
相比之下，Elasticsearch 使用专门的查询语言 ES DSL，最初为搜索设计，后期扩展了聚合等分析功能，采用 JSON 格式输入和输出，语法较复杂，与传统数据库体系差异显著，使用难度较高。
以下是一个示例：搜索指定时间段内，message 字段包含关键字 'error' 的数据，并按小时聚合统计和排序。这在日志和时序数据分析中非常常见。
在 Doris 中，执行相同操作仅需 7 行 SQL，而在 Elasticsearch 中则需要 30 行 DSL。关键不仅在于行数的差异，Elasticsearch 的 DSL 对初学者的门槛较高，即使是熟悉的用户也难以轻松编写。例如，简单需求的 DSL JSON 深度达到 6 层，而包含 2 块的情况则有 5 层，绝大多数人很难在不参考示例或手册的情况下自行编写。相比之下，SQL 的结构简单明了，使熟悉 SQL 的用户能够迅速上手。
1.5.2 查询能力
正如其名，Elasticsearch 擅长搜索，但在复杂分析查询方面表现较弱，例如多表 JOIN 和物化视图等。相较之下，Doris 是一款通用分析型数据库，提供强大的分析能力，包括搜索、聚合统计、多表 JOIN、UDF、子查询、窗口函数、逻辑视图、物化视图以及湖仓一体等功能。
1）搜索
尽管本文重点在实时分析场景下的对比，Elasticsearch 在搜索方面的优势仍值得一提。它基于 Apache Lucene 实现分布式搜索引擎，具备以下搜索能力：
- 精确匹配：支持等值和范围匹配，适用于数值、日期和不分词文本（Keyword）。前两者使用 BKD-Tree 索引，后者则使用倒排索引。
- 全文检索：支持关键词和短语的匹配。写入时，文本通过分词器分割，查询时直接通过词找到对应行，避免了传统数据库中逐行匹配的低效方式。此外，Elasticsearch 提供相关性打分、自动补全、拼写检查和搜索建议等高级功能，主要用于文档和网页检索。
- 向量检索：基于 ANN 向量索引，快速检索相似向量。
从 2.0 版本开始，Doris 也支持倒排索引和 BKD-Tree 索引，能够进行精确匹配和全文检索。向量检索目前通过向量距离函数实现，未来将支持向量索引加速。
在索引和搜索方面，Doris 和 Elasticsearch 存在两个重要区别：
- 面向不同场景的索引：Doris 不仅支持 Elasticsearch 的核心倒排索引和 BKD-Tree，还提供其他类型的索引以满足不同场景需求。索引分为两类：一类加速明细点查（主键索引、倒排索引），另一类加速分析查询（ZoneMap、BloomFilter、NGram BloomFilter）。这两类索引可以同时存在，支持混合场景。
- 以性能为中心的设计：Doris 的索引设计优先考虑性能，而非功能。例如，倒排索引采用轻量化设计，提供比 Elasticsearch 更优的写入和查询性能，但舍弃了一些在分析场景中使用频率较低的高级功能，如相关性打分、自动补全、拼写检查、搜索建议等。
因此，在分析场景中的精确匹配和全文检索（如 term、range、match、match_phrase 和 multi_match 等），Doris 完全能胜任且性能更佳。而对于文档和网页搜索，Elasticsearch 仍然是一个优秀的选择。
2）聚合
Doris 和 Elasticsearch 都支持丰富的聚合分析，包括：
- 基本聚合函数：
MIN、MAX、COUNT、SUM、AVG等。 - 高级聚合函数：
PERCENTILE（quantiles），HISTOGRAM（bucketed distributions） 等。 - 多种聚合模式：全局聚合和分组聚合（
GROPU BY）。
然而，两者在聚合分析上存在一些重要差异：
- 查询语法和易用性 ：Doris 使用标准 SQL 的聚合函数和
GROUP BY子句，使用简单明了。而 Elasticsearch 引入了许多新概念，如metric agg、bucket agg和pipeline agg，导致聚合结构更复杂，学习难度很高。 - 结果准确性：Elasticsearch 的聚合查询（如 bucket agg）默认返回近似结果。每个数据分片计算局部结果后，汇聚到协调节点，可能导致不准确的近似结果。相对而言，Doris 作为严肃的数据库，保证默认结果的准确性和高效性。
- 聚合查询性能：Doris 的分布式向量化查询经过高度优化，聚合查询性能显著优于 Elasticsearch。在后续的 ClickBench 测试中，可以看到 Doris 的性能是 Elasticsearch 的 6 到 21 倍。
2）JOIN
Elasticsearch 不支持 JOIN，因此在 TPC-H 和 TPC-DS 等常见基准测试中表现不佳。由于 JOIN 在数据分析中非常常见，Elasticsearch 提供了一些复杂的替代方案，但存在许多限制：
- Parent-child 和 has_child has_parent 查询：通过在一个索引中建立文档的父子关系来模拟 JOIN。子文档中包含父文档的 ID，has_child 查询先找到满足条件的子文档，然后通过子文档中的父 ID 获取父文档，has_parent 则相反。这种模式需要在写入数据时手动建立父子关系，复杂且不推荐与数据库的 JOIN 类比，且内存消耗和查询时间较高。
不建议使用多层关系来复制关系模型。每一层关系在查询时都会增加内存和计算的开销。为了获得更好的搜索性能，建议对数据进行去规范化处理。
- Terms Lookup：类似数据库的 IN 子查询，从一个 index 查询出 value list，然后用 terms 查询匹配 value list。此方法仅适合大表 JOIN 小表，针对大表与大表的 JOIN 性能较差。
相比之下，Doris 提供了完整的 JOIN 支持，包括：
- INNER JOIN
- CROSS JOIN
- LEFT / RIGHT / FULL OUTER JOIN
- LEFT / RIGHT SEMI JOIN
- LEFT / RIGHT ANTI JOIN
并且基于 Doris 智能优化器技术能够对多表 Join 规划出最优的执行计划，使得在 TPC-H 和 TPC-DS 基准测试以及在复杂生产场景的多表Join中表现优越。
4）在 Lakehouse 方面， Elasticsearch 不支持查询外部数据，自然也不支持数据湖查询加速和湖仓一体架构。Doris 通过多源数据目录（Multi-Catalog）功能，支持了包括 Apache Hive、Apache Iceberg、Apache Hudi、Apache Paimon、LakeSoul、Elasticsearch、MySQL、Oracle、SQL Server 等主流数据湖、数据库的连接访问。以及可以通过 Apache Ranger 等进行统一的权限管理。
1.5.3 查询性能
Doris 在多种场景和负载下表现出色，主键点查场景可达到几万 QPS，而分析场景的性能处于全球领先水平。相较之下，Elasticsearch 擅长搜索和点查，但在分析场景中的表现不佳。以下是一些对比测试结果：
在 Elasticsearch httplogs 和 Microsoft Azure logsbench 日志存储分析基准测试中，Doris 的查询性能是 Elasticsearch 的 3 倍以上，写入性能为其 3 ～ 4 倍，存储空间需求仅为 Elasticsearch 的 1/6 ～ 1/4。
ClickBench 是评估数据分析性能的基准测试，使用在线用户点击数据进行聚合统计等分析查询。Doris 的开箱即用性能是 Elasticsearch 的 21 倍，即使在 Elasticsearch 调优后，Doris 仍然快 6 倍。
用户案例
许多用户已在生产环境中用 Apache Doris 替代 Elasticsearch，并获得了令人振奋的成果。接下来，将分享一些来自可观察性、网络安全和实时业务分析领域的用户故事。
2.1 可观测场景
案例 1：国内知名短视频平台
该平台日增数据量达到 8000 亿条，存储容量为 500 TB，写入均值为 1000 万条/秒（60GB/s），峰值可达 3000 万条/秒（90GB/s）。
在 Log Trace 场景下，Apache Doris 需求绝大部分场景的导入性能要求。这种性能在全球范围内极为罕见，几乎没有其他系统能够承受如此压力，Elasticsearch 更是无从企及。
案例 2：网易
在网易灵犀 Eagle 监控平台，将 Elasticsearch 全面升级为 Doris，构建了统一的日志存储和分析平台。得益于 Doris 列式存储和 ZSTD 高压缩比，存储资源节省 70%；并在更低的资源占用下，Doris 的查询效率至少是 Elasticsearch 的 11 倍。
此外，在网易云信数据平台中，Doris 替代 InfluxDB，将其作为数据平台核心存储和计算引擎。实现服务器节省 50%，存储空间降低 67% 的显著收益。
案例 3：观测云
观测云使用 Doris 的商业化版本 SelectDB 替代了云上的 Elasticsearch。通过 SelectDB 的倒排索引能力、Variant 数据类型、冷热数据存储分层等特性，为观测云日志存储和分析场景服务注入强大的动力，实现存储成本降低 70% 的同时，查询性能提升 2-4 倍，最终实现整体性价比 10 倍提升。
2.2 网络安全场景
案例 1：奇安信
奇安信是网络安全领域领军企业， 基于 Doris 的安全日志存储解决方案，使得空间节省 40%，写入性能提升 2 倍，并在一个数据库系统中支持全文搜索、聚合分析和多表 JOIN 功能。
案例 2：中国电信翼支付
翼支付对安全的要求非常严格。过去，他们采用了 Presto、Hive 和 Elasticsearch 等多种工具来满足复杂的安全分析需求。现在，基于 Doris 的统一安全数据存储方案，导入性能提升了 4 倍，存储空间节省了 50%，查询性能也提高了 3 倍。
案例 3：安恒信息
使用 Doris 之后，写入性能提升了 2 倍，压缩率提升了 4 倍，查询性能也提高了 4 倍，显著优于 Elasticsearch。
2.3 业务分析领域
案例 1 ：头部短视频电商
过去，使用 Elasticsearch 支持直播详情页的在线查询时，面临着较高的成本和并发挑战。在替换为 Doris 后，写入性能从每秒 30 万次提升至 100 万次，查询并发能力也大幅提高，从 500 QPS 增至超过 2000 QPS。
案例 2：腾讯音乐内容库
此前，腾讯音乐使用了 Elasticsearch 和 ClickHouse 两个系统，以同时满足搜索和分析的需求。引入 Doris 后，腾讯音乐成功将这两个系统整合，实现了存储成本降低 80%、写入性能提升 4 倍，并支持复杂的分析功能。
案例 3：360 企业安全浏览器
360 企业安全浏览器所搭建的数据平台主要提供日志检索和报表分析。通过采用 Doris，成功将 Elasticsearch 和其他系统整合在一起，聚合分析效率提升了 100%，存储空间减少了 60%，SQL 开发效率提升超过 1 倍。
结束语
Apache Doris 是专门为实时分析设计的数据库，实现了优秀的列式存储、向量化执行引擎、分布式 MPP 架构、RBO & CBO 查询优化器，在单表 ClickBench、SSB，多表关联 TPC-H / TPC-DS 等多个典型 BenchMark 中性能全球领先，性能比 ElasticSearch 快一个量级，被全球 5000 多家中大型企业应用于实时报表与分析、用户画像与行为分析、湖仓一体等场景。
从 2.0 版本开始，Apache Doris 支持倒排索引，满足之前使用 Elasticsearch 才能满足的全文检索需求，应用场景扩展到日志存储分析和可观测性，被数百家中大型企业使用，成本比 Elasticsearch 降低 5 ～ 10 倍。
从 3.0 版本开始，Apache Doris 支持存算分离模式，可以进一步降低成本 50% 以上，而且更好地支持计算负载隔离和弹性扩展。
从 4.0 版本开始（预计 2025 年 6 月发布），Apache Doris 将支持服务于大模型场景的 HybridSearch 能力，同时提供实时数据分析、全文检索和向量检索的能力，打造一个服务于实时分析和 GenAI 场景最快的数据库。