Elasticsearch 是一款开源的分布式检索引擎，广泛应用于实时分析、日志分析、全文搜索和数据监控等领域。凭借其强大的实时搜索能力和灵活的查询语言，在市场上获得了广泛认可。然而，在过去两年，我们注意到一个趋势，很多 Elasticsearch 用户倾向于采用 Apache Doris 替代 Elasticsearch。
本文将从技术选型的视角，全方位深度解析 Apache Doris 与 Elasticsearch 的差异，包括以下几点：
- 开源开放：开源和开放的程度决定了用户是否会被供应商锁定。
- 系统架构：系统架构决定了系统的部署模式和依x赖的软硬件要求。
- 实时写入：系统部署完成后，用户首要关注数据写入的方式及效率。
- 实时存储：数据写入后采用何种数据模型存储，以及存储成本的考量也至关重要。
- 实时查询：数据的写入和存储最终目的是提供查询，丰富的查询能力和高效的查询性能是用户通过数据库实现业务价值的关键。
深入对比
1.1 开放性
产品的开放性影响了用户的选择，大多数用户倾向于选择更加开放的产品或项目。Apache Doris 是 Apache 软件基金会的开源项目，采用 Apache Licence 2.0 协议，保持开源和中立性。而 Elasticsearch 由 Elastic 公司管理，许可证可随需调整，目前 Elasticsearch 已经历了 3 次协议变更。
1.2 系统架构
系统架构决定了用户的部署方式，以及所需的软硬件资源。Apache Doris 支持多种部署模型，且在 3.0 版本后支持存算分离和存算一体两种架构，用户可根据需求灵活选择。Elasticsearch 只支持存算一体的部署模式，在资源弹性、负载隔离、存储分层方面有明显劣势。
1.3 实时写入
系统部署完成后，下一步是数据写入。Doris 和 Elasticsearch 在数据写入上存在显著差异，主要体现在写入方式和性能两个方面。
1.3.1 写入方式
数据写入通常有两种方式：推（Push）模式和拉（Pull）模式。在推模式下，外部系统通过 API 将数据写入数据库；而在拉模式下，数据库主动从外部数据源（如 Kafka）拉取数据并存储。
Elasticsearch 仅支持推模式，提供 HTTP API。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 默认采用紧凑的列式存储，提高相似数据的压缩率并可高效读取数据，此外实现了实现 ZSTD 压缩算法，其压缩率高于常用的 GZIP 和 LZ5。并针对分析场景简化倒排索引，去掉行存以节省大量存储空间。
Elasticsearch 默认使用行存，行存是查询原始明细数据的必要条件。由于存储模型的差异，Elasticsearch 通常需要存储行存、列存和倒排索引三份数据，而行存的压缩率较低，导致存储空间和成本高昂。
使用与上节相同的配置及参数进行 httplogs 对比测试，在创建相同倒排索引的前提下，Elasticsearch 占用 19.4GB，而 Doris 仅占 3.2GB，存储空间降低了 83%，意味着 Doris 所需存储成本不到 Elasticsearch 的 1/5。
1.4.2 数据模型
Elasticsearch 和 Doris 都支持三种常用的数据模型：明细模型、主键模型和聚合模型，但对后两者的支持程度差异较大。具体差异见下图：
在主键模型方面，在 Elasticsearch 中，特殊的 _id 字段类似于数据库的主键，用于唯一标识文档（相当于数据库的一行），并允许覆盖和更新，但存在字段长度、使用场景有限等问题。相比之下，Doris 的主键模型符合常规数据库标准，允许用户指定一个或多个字段作为唯一主键，并没有特别限制。
在聚合模型方面，Elasticsearch 也存在局限性，比如仅适用于时序数据，原始 Index 与 Downsampling Index 不能共存，且原始 Index 必须处于只读状态，正在写入的数据无法进行聚合采样等。相比之下，Doris 作为实时数仓，通过**聚合物化视图或 Rollup、聚合表** 提供了强大的聚合能力。聚合物化视图在数据写入时自动更新，确保基础表与视图的同步，为查询提供加速；聚合表直接存储聚合后的数据，显著降低存储空间。
Doris 的聚合分析具有以下优势：不限制数据类型，支持时序数据和业务报表；灵活存储原始数据；实时更新并保证数据的原子性；透明的查询体验，用户需关注底层的物化视图可直接执行聚合查询；丰富的聚合能力，支持常用的 min、max、count、sum、avg 等聚合操作，还包括复杂的 bitmap_union，用于精确去重等场景。
1.4.3 Flexible Schema
在许多实时在线场景中，随着业务的发展，用户需要在不中断服务的情况下修改数据 Schema，例如新增或删除字段和索引。因此，Flexible Schema 的支持程度直接影响线上业务的可用性。以下表格对比了 Doris 和 Elasticsearch 对 Flexible Schema 的支持情况：
Elasticsearch 通过 Dynamic Mapping 支持一定程度的 Flexible Schema，允许在写入 JSON 数据时自动添加新字段到 Index Mapping。然而，它不允许删除已有字段，用户只能创建新 Index 并通过 Reindex 操作迁移数据，这一过程既耗时又消耗资源。此外，Elasticsearch 不支持在现有字段上增加索引，用户必须通过 Reindex 实现，用户还无法修改字段或 Index 名称，Reindex 后需使用新名称，这对上层业务不友好。
相比之下，Doris 支持多种常见的 Schema Change 操作，包括修改字段和表名、增删字段和索引。新增索引对新数据立即生效，而历史数据可通过后台增量异步构建，不影响正常的写入和查询。这种灵活的在线 Schema Change 为业务发展提供了更大的自由度。
1.5 实时查询
数据的写入和存储最终是为了支持查询，而查询的功能和性能是实现业务价值的关键。接下来，我们将从查询的易用性、功能和性能方面对比 Doris 和 Elasticsearch。
1.5.1 查询易用性
Doris 提供了简单易用的标准 SQL 查询接口，并与 MySQL 协议兼容，用户可以通过 MySQL 的 CLI、JDBC 和 ODBC 直接访问 Doris。相比之下，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）在索引和搜索方面，具体差异如下：
Doris 和 Elasticsearch 存在两个重要区别：
- 面向不同场景的索引：Doris 不仅支持 Elasticsearch 的核心倒排索引和 BKD-Tree，还提供其他类型的索引以满足不同场景需求。索引分为两类：一类加速明细点查（主键索引、倒排索引），另一类加速分析查询（ZoneMap、BloomFilter、NGram BloomFilter）。这两类索引可以同时存在，支持混合场景。
- 以性能为中心的设计：Doris 的索引设计优先考虑性能，而非功能。例如，倒排索引采用轻量化设计，提供比 Elasticsearch 更优的写入和查询性能，但舍弃了一些在分析场景中使用频率较低的高级功能，如相关性打分、自动补全、拼写检查、搜索建议等。
因此，在分析场景中的精确匹配和全文检索（如 term、range、match、match_phrase 和 multi_match 等），Doris 完全能胜任且性能更佳。而对于文档和网页搜索，Elasticsearch 仍然是一个优秀的选择。
2）在聚合方面，具体差异如下：
Doris 和 Elasticsearch 虽然都支持丰富的聚合分析，但也存在一些重要差异：
- 查询语法和易用性：Doris 使用标准 SQL 的聚合函数和
GROUP BY子句，使用简单明了。而 Elasticsearch 引入了许多新概念，如metric agg、bucket agg和pipeline agg，聚合结构更复杂、学习难度很高。 - 结果准确性：Elasticsearch 的聚合查询（如 bucket agg）默认返回近似结果。每个数据分片计算局部结果后，汇聚到协调节点，可能导致不准确的近似结果。相对而言，Doris 作为严肃的数据库，保证默认结果的准确性和高效性。
- 聚合查询性能：Doris 的分布式向量化查询经过高度优化，聚合查询性能显著优于 Elasticsearch。在后续的 ClickBench 测试中，可以看到 Doris 的性能是 Elasticsearch 的 6 到 21 倍。
3）在 JOIN 方面， Elasticsearch 不支持 JOIN，因此在 TPC-H 和 TPC-DS 等常见基准测试中表现不佳。而 Doris 提供了完整的 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 和 Elasticsearch 在查询性能上的差异如下：
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 场景最快的数据库。
我们鼓励大家加入 Apache Doris 社区，并参与 Elasticsearch 到 Doris 的专项交流群（长按下方二维码，回复 ES 进群），以获取技术帮助、了解最新动态，并与更多开发者和用户互动。
