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 的寫入吞吐，這得益於多項優化：

1. 採用 C++ 實現，運行效率高於 Elasticsearch 及其底層 Java。
2. 全鏈路向量化執行引擎充分利用 CPU SIMD 指令，加速數據寫入和倒排索引構建，列式存儲和索引便於向量化優化。
3. 針對實時分析場景優化倒排索引，去掉不必要的正排和 norm 存儲結構，更加輕量高效。
4. 僅需在一個副本中構建索引，其他副本通過拷貝避免重複的 CPU 消耗。
5. 優化後台合併（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 場景最快的數據庫。