01Apache Doris を選ぶ場面

Doris と ClickHouse は、どちらも代表的なリアルタイム分析データベースです。Doris は、データチームが日常的に扱うワークロードで強みを発揮します。

↑2–10×
高速な結合

複数テーブルの分散結合。ワイドテーブルへの変換は不要です。

MPP アーキテクチャとコストベースオプティマイザが、Broadcast、Shuffle、Colocate の各結合方式を自動選択します。Doris は TPC-DS の全クエリを完了しますが、ClickHouse は約 50% のクエリで失敗します。

↓70%
コスト削減

オープンソースのストレージ・コンピュート分離。

リバランスなしでコンピュートを柔軟に拡張できます。このコスト構造はオープンソースの 3.0 以降で利用でき、商用クラウドへのロックインはありません。

1000+
同時実行クエリ

クエリ速度を維持したまま、リアルタイムに UPSERT。

Merge-on-Write により、高頻度の更新中も安定した読み取り性能を維持します。完全な ACID、MySQL 互換性を備え、100 未満ではなく数千のクエリを同時実行できます。

02注目の導入事例

インターネット規模の企業による本番移行事例。同じ SQL ワークロードでも、結果は大きく変わります。

事例 01★ 注目事例

ClickHouse を Apache Doris に置き換えた Kuaishou は、統合レイクハウスアーキテクチャへの移行を実現し、ストレージを統合してデータパイプラインを簡素化しました。

レイクハウスへの直接クエリ:取り込み不要でパイプラインを短縮
マテリアライズドビューによるクエリ書き換え でさまざまなクエリを高速化
柔軟な データガバナンス を自動マテリアライズで実現
事例 02★ 注目事例

分析エンジンを ClickHouse から Apache Doris に移行し、データの鮮度を改善するとともに、運用コストを削減し、データ管理の分断を解消しました。

優れた 複数テーブル結合 と フェデレーテッドクエリ の性能
MySQL プロトコル互換:運用負荷を軽減
一部カラムの更新 で多様なデータ更新パターンに対応
事例 03★ 注目事例

Apache Doris は、ほとんどのシナリオで ClickHouse よりもクエリ応答が速く、特に複雑な結合では大幅に優れた性能を発揮します。

主要な業務クエリが 2~3 倍高速に
複雑な結合クエリが 2~10 倍高速に
実行に成功: ClickHouse でメモリ不足になったすべての クエリ
03主な違い

重要な観点を並べて比較します。

比較項目
Apache Doris推奨
ClickHouse
01システムアーキテクチャ
  • MPP 分散アーキテクチャ
  • MySQL プロトコル互換・標準 SQL
  • CBO による自動最適化
  • Scatter-Gather アーキテクチャ
  • SQL に似た独自構文
  • 手動チューニングが必要
02結合クエリの性能
  • ノード間の分散結合で 2~10 倍高速
  • CBO が結合方式を選択
  • TPC-DS の全クエリを完了
  • 効率的なメモリ利用で OOM を回避
  • サブクエリとワイドテーブルのモデル化
  • CBO がなく、手動調整が必要
  • TPC-DS クエリの約 50% が失敗
  • 大規模クエリでメモリ不足が頻発
03リアルタイム更新
  • Merge-on-Write エンジン
  • 強い整合性・更新を即座に参照可能
  • 高スループットの UPSERT、性能劣化なし
  • ReplacingMergeTree・結果整合性
  • FINAL により 2~10 倍低速化
  • 高頻度の更新でマージ負荷が増大
04トランザクション対応
  • 完全な ACID トランザクション
  • アトミックなバッチ取り込み
  • トランザクション非対応
  • 一部のデータだけが見える場合がある
05クエリ同時実行数
  • 数千の同時クエリ、10 倍以上
  • 効率的なメモリ管理
  • 通常は同時実行数 100 未満
  • メモリ負荷の高い処理でクラスタが不安定化
06データ API とレイクハウス
  • 高スループットの Arrow Flight プロトコル
  • Hive / Hudi / Iceberg / Parquet
  • 自動スケーリングと複数レプリカの負荷分散
  • JDBC のみ
  • レイクハウス連携が限定的
  • 拡張時に手動リバランスが必要
07ストレージ・コンピュート分離
  • オープンソースの 3.0 以降で提供
  • コンピュートを柔軟に拡張、リバランス不要
  • 最大 70% のコスト削減
  • 商用クラウド版のみ
  • 密結合のため、拡張時にリバランスが必要
  • ピークに備えた過剰なリソース確保が必要
08オープンソースライセンス
  • Apache 財団の下でコミュニティが保守
  • 商用企業が管理