01為什么選擇 SelectDB
Doris 與 ClickHouse 都是全球領先的實時分析型數(shù)據(jù)庫。SelectDB（基于 Apache Doris）在現(xiàn)代數(shù)據(jù)團隊日常運行的工作負載上更具優(yōu)勢。
↑2–10×
更快的多表關聯(lián)
分布式多表 Join，無需寬表變通方案
MPP 架構配合基于成本的優(yōu)化器（CBO），自動選擇廣播、Shuffle 或 Colocate Join。SelectDB 完整通過 TPC-DS 全部查詢；ClickHouse 約 50% 查詢失敗。
↓70%
更低的成本
存算分離架構，全托管云原生服務
彈性計算資源，擴縮容無需數(shù)據(jù)重分布。SelectDB Cloud 提供 SaaS 與 BYOC 模式，已上線阿里云、華為云、騰訊云、AWS，無商業(yè)廠商鎖定。
1000+
高并發(fā)查詢
實時 UPSERT 不影響查詢速度
Merge-on-Write 引擎保持高頻更新下的穩(wěn)定讀取。完整 ACID 事務，兼容 MySQL 協(xié)議，支持數(shù)千并發(fā)查詢而非不到 100。
02核心差異
逐維度并排對比，覆蓋所有關鍵指標。
| SelectDB 推薦 | ClickHouse |
|---|
| 系統(tǒng)架構 | MPP 分布式架構
兼容 MySQL 協(xié)議，標準 SQL
CBO 自動優(yōu)化 | Scatter-Gather 架構
類 SQL 語法，非標準
需手動調優(yōu) |
| 多表關聯(lián) | 2–10× 更快，跨節(jié)點分布式
CBO 選擇最優(yōu) Join 策略
完整通過 TPC-DS
高效內存管理，避免 OOM | 子查詢 + 寬表建模
無 CBO，手動調優(yōu)
約 50% 查詢失敗
大查詢頻繁 OOM |
| 實時更新 | Merge-on-Write 引擎
強一致性，寫入即可見
高吞吐 UPSERT，性能無退化 | ReplacingMergeTree，最終一致
FINAL 關鍵字導致嚴重慢查詢
高頻更新時后臺合并開銷巨大 |
| 事務支持 | 完整 ACID 事務
原子性批量導入 | 無事務支持
部分數(shù)據(jù)可能提前可見 |
| 查詢并發(fā) | 數(shù)千并發(fā)查詢，10×+
高效內存管理 | 通常低于 100 并發(fā)
內存密集型負載導致集群不穩(wěn)定 |
| 數(shù)據(jù) API | Arrow-Flight 高吞吐協(xié)議
支持 Hive / Hudi / Iceberg / Parquet
自動擴縮容 + 多副本平衡 | 僅 JDBC
湖倉集成能力有限
擴縮容需手動平衡 |
| 存算分離 | 開源 3.0+
彈性計算，擴縮無需 Rebalance
最高降低 70% 成本 | 僅商業(yè)云版支持
緊耦合，擴縮需數(shù)據(jù)重分布
高峰期需過量預留資源 |
| 開源許可 | Apache 基金會，社區(qū)維護 | 由商業(yè)公司控制 |
03精選案例
來自互聯(lián)網(wǎng)頭部企業(yè)的真實生產遷移實踐。
利用 Apache Doris 替換 ClickHouse 后，快手成功升級為湖倉一體架構，實現(xiàn)統(tǒng)一存儲并簡化數(shù)據(jù)鏈路，無需數(shù)據(jù)導入即可直接訪問湖倉數(shù)據(jù)。
? 直接查詢數(shù)據(jù)湖，縮短數(shù)據(jù)鏈路
? 物化視圖改寫，加速多場景查詢
? 自動物化服務，實現(xiàn)靈活數(shù)據(jù)治理
內容庫數(shù)據(jù)平臺從 ClickHouse 遷移到 Apache Doris 后，有效提高了數(shù)據(jù)時效性、降低了運維成本、解決了數(shù)據(jù)管理割裂等問題。
? 多表查詢和聯(lián)邦查詢性能卓越
? 兼容 MySQL 協(xié)議，降低運維成本
? 部分列更新，滿足多樣更新方式
用 Apache Doris 替換 ClickHouse 構建新日志平臺，系統(tǒng)在查詢響應、并發(fā)處理、穩(wěn)定性及運維效率等多方面均取得顯著提升。
? 全文檢索性能提升 3-7 倍
? 峰值寫入吞吐達 6GB/s
? 支持 500+ 并發(fā)，較 CK 提升超 2 倍
01為什么選擇 SelectDB
Elasticsearch 與 Apache Doris 在可觀測性、網(wǎng)絡安全和實時分析領域均有廣泛應用。SelectDB 以極低的存儲成本、更快的分析查詢和豐富的 SQL 能力脫穎而出。
↓5-10×
超高壓縮比
存儲壓縮率高達 1:10，對比 ES 僅 1:1.5
列式存儲配合高級編碼技術，實現(xiàn) 5-10 倍更優(yōu)壓縮率。顯著降低日志和可觀測性工作負載的存儲成本。
↑3-4×
更高寫入吞吐
多副本一次索引 vs ES 多次索引開銷
Doris 一次寫入多副本復制，而 ES 需要對每個副本分別索引。加上列式存儲優(yōu)勢，Doris 在更低 CPU 成本下實現(xiàn) 3-4 倍更高寫入吞吐。
SQL
標準查詢接口
MySQL 兼容 SQL vs 專有 DSL
完整多表 JOIN、子查詢、物化視圖和 UDF。懂 SQL 即可上手，零學習成本。開放 MySQL 生態(tài) vs 封閉 ES 生態(tài)。
02核心差異
逐維度并排對比，覆蓋所有關鍵指標。
| SelectDB 推薦 | Elasticsearch |
|---|
| 開源許可 | Apache License 2.0
由 Apache 基金會運營 | 多次變更（Apache → Elastic → AGPL）
由 Elastic 公司運營 |
| 系統(tǒng)架構 | 更靈活彈性：
嚴格讀寫分離與業(yè)務負載隔離
支持存算一體和存算分離 | 有限彈性：
線程組方式，僅弱計算隔離
僅支持存算一體 |
| 實時寫入 | 高吞吐低開銷：
多副本一次索引
支持 Push + Pull 兩種寫入方式
兼容 Logstash & Beats | 寫入吞吐低、開銷高
多副本多次索引
僅支持 Push 寫入
Pull 需借助 Logstash |
| 存儲效率 | 壓縮率 1:5 — 1:10
主鍵模型支持 MoW + MoR
聚合模型強一致同步
靈活 Schema Change | 壓縮率僅 1:1.5
主鍵模型僅支持 MoW
聚合模型異步最終一致
有限 Schema Change |
| 查詢分析 | 多種負載極速響應
多表 Join + 物化視圖 + UDF
標準 SQL，零學習成本
開放 MySQL 生態(tài) | 點查性能高，分析性能低
不支持多表 Join
專有 DSL，學習門檻高
私有 ES 生態(tài) |
| 部署方式 | 三種部署模式：
SaaS / BYOC 云托管 + 本地部署
已上線阿里云、華為云、騰訊云、AWS | 僅 SaaS 和本地部署
無 BYOC 模式 |
03精選案例
來自金融、物流行業(yè)頭部企業(yè)的可觀測平臺升級實踐。
基于 Apache Doris 替換 Elasticsearch 構建日志存儲與分析平臺，減少了日志冗余存儲，提高了存儲效率，同時提供強大高效的日志檢索與分析服務。
? 資源投入節(jié)省 50%
? 查詢效率提升 2~4 倍
? 支持 JOIN，滿足復雜分析需求
之前采用多個組件構建安全分析系統(tǒng)，存在數(shù)據(jù)冗余問題。借助 Apache Doris 統(tǒng)一架構后，系統(tǒng)在寫入吞吐、查詢響應及存儲效率均實現(xiàn)顯著優(yōu)化。
? 寫入速度提升 4 倍
? 查詢性能提升 3 倍
? 存儲空間節(jié)省 50%
引入 Doris 替換原有 OLAP 數(shù)據(jù)庫后，查詢性能提升 5-10 倍，并發(fā)能力達 2 倍提升。90% 分析場景處理時間從 10 分鐘縮短至 1 分鐘以內。
? 高并發(fā)分析提升 2 倍
? 存儲空間節(jié)省 65%
? 標準 SQL，簡化運維使用
01為什么選擇 SelectDB
Doris 與 Trino/Presto 均為主流數(shù)據(jù)湖倉查詢引擎，但 SelectDB 性能更優(yōu)，還能作為獨立數(shù)據(jù)倉庫運行——統(tǒng)一整體數(shù)據(jù)架構。
↑10×
內表查詢性能
Doris 內表查詢最高可達 Trino 的 10 倍
C++ 原生向量化引擎遠優(yōu)于 Java 引擎。CBO 優(yōu)化器配合三層緩存（元數(shù)據(jù)、數(shù)據(jù)、查詢），實現(xiàn)數(shù)量級更快的響應。
↑2-3×
湖倉查詢加速
即使針對外部 Hive 表，Doris 也比 Trino 快 2-3 倍
高級查詢優(yōu)化 + 本地 SSD 熱數(shù)據(jù)緩存大幅減少網(wǎng)絡 I/O。Trino 依賴 Alluxio 等外部緩存方案。
統(tǒng)一
統(tǒng)一平臺
一個引擎替代數(shù)倉 + 湖倉查詢層
內置存儲引擎滿足高性能數(shù)倉需求，同時具備原生湖倉查詢能力。簡化技術棧，降低 30%+ 資源成本。
02核心差異
逐維度并排對比，覆蓋所有關鍵指標。
| SelectDB 推薦 | Trino/Presto |
|---|
| 系統(tǒng)架構 | 統(tǒng)一架構：融合數(shù)據(jù)倉庫與數(shù)據(jù)湖查詢能力 | 聯(lián)邦查詢：擅長跨異構數(shù)據(jù)源查詢，但無內置存儲層 |
| 執(zhí)行引擎 | C++ 全向量化引擎，高性能數(shù)據(jù)處理 | Java 向量化引擎，Hummingbird 項目開發(fā)中 |
| 查詢優(yōu)化 | CBO 優(yōu)化器，自動優(yōu)化復雜 JOIN、聚合、排序 | 統(tǒng)計信息收集不完善，需手動全量收集 |
| 緩存機制 | 三層緩存：元數(shù)據(jù) TTL 緩存 + SSD 數(shù)據(jù)緩存 + SQL/分區(qū)查詢緩存 | 依賴 Alluxio 等外部緩存方案 |
| 物化視圖 | 增量刷新 + 多種刷新策略
查詢透明加速：自動匹配最優(yōu)物化視圖 | 僅支持人工全量刷新 |
| 應用場景 | 高并發(fā)實時分析 + 交互式分析 | 僅交互式分析 |
03精選案例
來自中國互聯(lián)網(wǎng)企業(yè)的技術棧統(tǒng)一與查詢加速實踐。
早期使用 Trino、SparkSQL 等系統(tǒng)構建數(shù)據(jù)平臺，導致架構復雜、數(shù)據(jù)重復。引入 Apache Doris 替換多技術棧，實現(xiàn)湖倉統(tǒng)一查詢，查詢性能提升 3 倍以上。
? 統(tǒng)一數(shù)據(jù)倉庫與湖倉引擎
? 簡化技術棧，降低運維復雜度
? 查詢延遲從分鐘降至秒級
網(wǎng)易游戲
游戲 · 數(shù)據(jù)中臺
遷移到 Doris 后，之前 Presto 多維分析查詢從 20-40 秒 縮短至 1-2 秒。自動識別并匹配最優(yōu)物化視圖，進一步增強復雜分析性能。
? 內表查詢性能最高提升 10 倍
? 自動物化視圖加速查詢
? 零手動優(yōu)化，開箱即用
使用 Trino 和 SparkSQL 時，查詢延遲維持在分鐘級別。遷移至 Doris 后整體查詢性能提升 2 倍以上，有效解決了混合架構下的數(shù)據(jù)孤島問題。
? 湖倉查詢快 2-3 倍
? 分鐘級延遲降至秒級
? 消除數(shù)據(jù)孤島
01為什么選擇 SelectDB
SelectDB 專為實時數(shù)據(jù)分析打造，具備極強的擴展性。Snowflake 是云數(shù)據(jù)倉庫與分析平臺。在實時分析場景中，SelectDB 以更高并發(fā)、更快查詢、極低成本脫穎而出。
02核心差異
逐維度并排對比，覆蓋所有關鍵指標。
| SelectDB 推薦 | Snowflake |
|---|
| 部署方式 | 三種部署模式：SaaS 云原生服務（AWS/Azure/GCP）
BYOC 云原生服務
本地企業(yè)級部署 | 僅支持云 SaaS |
| 實時更新 | 高吞吐實時更新，每秒百萬條記錄
從 Flink、Kafka、API 實時消費數(shù)據(jù)，秒級可見 | 不適合頻繁數(shù)據(jù)更新
僅支持批量數(shù)據(jù)攝入 |
| 數(shù)據(jù) API | Arrow Flight 高速讀取協(xié)議 | 僅支持 JDBC/ODBC 低速讀取 |
| 豐富索引 | Skip Index：MinMax、BloomFilter
點查索引：Prefix Index、倒排索引 | 僅支持 Skip Index（MinMax、BloomFilter） |
| 物化視圖 | 同步物化視圖，實時刷新
異步物化視圖，多表關聯(lián) | 不支持實時刷新
不支持異步物化視圖 |
| 適用場景 | 實時分析 + 數(shù)據(jù)倉庫 + 湖倉一體
日志與可觀測性 | 數(shù)據(jù)倉庫與湖倉一體
不適合實時分析 |
03客戶實證
遷移到 SelectDB 作為實時分析平臺后，查詢速度提升了 3-10倍，成本相比 Snowflake 下降了近 50%。SelectDB 對復雜搜索、多表關聯(lián)和多樣化聚合分析等場景的強大支持，完美滿足了我們快速、靈活的分析需求。
— 全球領先 SaaS 廠商
01為什么選擇 SelectDB
Redshift 是 AWS 云數(shù)據(jù)倉庫，SelectDB 是新一代實時數(shù)據(jù)倉庫。在實時分析、并發(fā)處理、成本控制等方面，SelectDB 展現(xiàn)出明顯優(yōu)勢，同時支持多云部署。
02核心差異
逐維度并排對比，覆蓋所有關鍵指標。
| SelectDB 推薦 | Redshift |
|---|
| 部署方式 | 三種部署模式：SaaS / BYOC / 本地
支持阿里云、華為云、騰訊云、AWS、Azure、GCP | 僅 AWS 云 SaaS
無法跨云或本地部署 |
| 實時更新 | 高吞吐實時 UPSERT，每秒百萬條
支持 Flink/Kafka 流式寫入，秒級可見 | 以批量導入為主
不適合高頻數(shù)據(jù)更新 |
| 并發(fā)能力 | 數(shù)千并發(fā)查詢
高效內存管理，穩(wěn)定運行 | 并發(fā)有限，高并發(fā)場景性能下降明顯
需預留大量資源 |
| 查詢性能 | 分布式 MPP + C++ 向量化引擎
多表 Join 性能優(yōu)異
ClickBench 全球領先 | 基于 PostgreSQL 修改
復雜 Join 和大表分析性能較弱
對非列存優(yōu)化場景慢 |
| 數(shù)據(jù)格式 | 開放格式（Parquet/Iceberg/Hudi）
湖倉一體，無需鎖入 | 專有列存格式
數(shù)據(jù)遷移困難，廠商鎖定風險高 |
| 生態(tài)兼容 | MySQL 協(xié)議兼容
標準 SQL，零學習成本
開放生態(tài)集成 | 基于 PostgreSQL 協(xié)議
部分 SQL 語法不同
需學習 Redshift 專有特性 |
| 計費模式 | 存算分離，按實際使用付費
SaaS 免費試用 + BYOC 靈活定價 | 按節(jié)點規(guī)格固定付費
高峰期需過量預留、成本高 |
03客戶實證
從 Redshift 遷移到 SelectDB 后，團隊實現(xiàn)了 5-10倍的查詢加速，同時成本下降了近 60%。更重要的是，SelectDB 支持實時數(shù)據(jù)攝入和 MySQL 兼容，讓我們無需額外學習成本即可快速上手。
— 全球領先互聯(lián)網(wǎng)企業(yè)
