Elasticsearch 是一款开源的分布式检索引擎，广泛应用于实时分析、日志分析、全文搜索和数据监控等领域。凭借其强大的实时搜索能力和灵活的查询语言，在市场上获得了广泛认可。然而，在过去两年，我们注意到一个趋势，很多 Elasticsearch 用户倾向于采用 Apache Doris 替代 Elasticsearch。
本文将从技术选型的视角，全方位深度解析 Apache Doris 与 Elasticsearch 的差异，包括以下几点：
1. 深入对比
产品的开放性影响了用户的选择，大多数用户倾向于选择更加开放的产品或项目。Apache Doris 是 Apache 软件基金会的开源项目，采用 Apache Licence 2.0 协议，保持开源和中立性。而 Elasticsearch 由 Elastic 公司管理，许可证可随需调整，目前 Elasticsearch 已经历了 3 次协议变更。
1.2 系统架构
系统架构决定了用户的部署方式，以及所需的软硬件资源。Apache Doris 支持多种部署模型，且在 3.0 版本后支持存算分离和存算一体两种架构，用户可根据需求灵活选择。Elasticsearch 只支持存算一体的部署模式，在资源弹性、负载隔离、存储分层方面有明显劣势。
Apache Doris 存算一体、存算分离部署方式
1.3 实时写入
系统部署完成后，下一步是数据写入。Doris 和 Elasticsearch 在数据写入上存在显著差异，主要体现在写入方式和性能两个方面。
1.3.1 写入方式
数据写入通常有两种方式：推（Push）模式和拉（Pull）模式。在推模式下，外部系统通过 API 将数据写入数据库；而在拉模式下，数据库主动从外部数据源（如 Kafka）拉取数据并存储。
Elasticsearch 仅支持推模式，提供 HTTP API。Doris 则同时支持推和拉两种模式，它提供 HTTP API 和 JDBC API 进行推写，同时支持内置的 Routine Load（https://doris.apache.org/docs/3.0/data-operate/import/import-way/routine-load-manual） 从 Kafka 拉取数据，以及通过 Multi-Catalog 从对象存储、HDFS 和其他数据库同步数据到 Doris 。此外，Doris 还支持 Elasticsearch 生态中的 Logstash 和 Beats ，通过 Doris Output Plugin、Logstash 、Beats 将数据写入 Doris。
Doris 提供了一种特殊的批量写入事务机制（https://doris.apache.org/docs/3.0/data-operate/transaction），既保证事务性又实现高吞吐。在批量写入时设置唯一标签，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（https://doris.apache.org/docs/query-acceleration/materialized-view/sync-materialized-view）、聚合表（https://doris.apache.org/docs/3.0/table-design/data-model/aggregate）提供了强大的聚合能力。聚合物化视图在数据写入时自动更新，确保基础表与视图的同步，为查询提供加速；聚合表直接存储聚合后的数据，显著降低存储空间。
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 倍。
2. 用户案例
2.1 可观测场景
该平台日增数据量达到 8000 亿条，存储容量为 500 TB，写入均值为 1000 万条/秒（60GB/s），峰值可达 3000 万条/秒（90GB/s）。
在 Log Trace 场景下，Apache Doris 需求绝大部分场景的导入性能要求。这种性能在全球范围内极为罕见，几乎没有其他系统能够承受如此压力，Elasticsearch 更是无从企及。
在网易灵犀 Eagle 监控平台，将 Elasticsearch 全面升级为 Doris，构建了统一的日志存储和分析平台。得益于 Doris 列式存储和 ZSTD 高压缩比，存储资源节省 70%；并在更低的资源占用下，Doris 的查询效率至少是 Elasticsearch 的 11 倍。
此外，在网易云信数据平台中，Doris 替代 InfluxDB，将其作为数据平台核心存储和计算引擎。实现服务器节省 50%，存储空间降低 67% 的显著收益。
观测云使用 Doris 的商业化版本 SelectDB 替代了云上的 Elasticsearch。通过 SelectDB 的倒排索引能力、Variant 数据类型、冷热数据存储分层等特性，为观测云日志存储和分析场景服务注入强大的动力，实现存储成本降低 70% 的同时，查询性能提升 2-4 倍，最终实现整体性价比 10 倍提升。
2.2 网络安全场景
奇安信是网络安全领域领军企业， 基于 Doris 的安全日志存储解决方案，使得空间节省 40%，写入性能提升 2 倍，并在一个数据库系统中支持全文搜索、聚合分析和多表 JOIN 功能。
翼支付对安全的要求非常严格。过去，他们采用了 Presto、Hive 和 Elasticsearch 等多种工具来满足复杂的安全分析需求。现在，基于 Doris 的统一安全数据存储方案，导入性能提升了 4 倍，存储空间节省了 50%，查询性能也提高了 3 倍。
使用 Doris 之后，写入性能提升了 2 倍，压缩率提升了 4 倍，查询性能也提高了 4 倍，显著优于 Elasticsearch。
2.3 业务分析领域
过去，使用 Elasticsearch 支持直播详情页的在线查询时，面临着较高的成本和并发挑战。在替换为 Doris 后，写入性能从每秒 30 万次提升至 100 万次，查询并发能力也大幅提高，从 500 QPS 增至超过 2000 QPS。
此前，腾讯音乐使用了 Elasticsearch 和 ClickHouse 两个系统，以同时满足搜索和分析的需求。引入 Doris 后，腾讯音乐成功将这两个系统整合，实现了存储成本降低 80%、写入性能提升 4 倍，并支持复杂的分析功能。
360 企业安全浏览器所搭建的数据平台主要提供日志检索和报表分析。通过采用 Doris，成功将 Elasticsearch 和其他系统整合在一起，聚合分析效率提升了 100%，存储空间减少了 60%，SQL 开发效率提升超过 1 倍。
3. 结束语
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 场景最快的数据库。
文章评论