ClickHouseとDuckDBは、どちらも「高速なOLAPデータベース」という見出しで語られますが、設計思想は対照的です。ClickHouseはサーバー型で大規模リアルタイム分析向け、DuckDBはインプロセス型でローカル探索向けです。本記事では両者の特徴を整理し、ユースケース別の使い分けを解説します。ログ/イベント分析ならClickHouse、PoCや開発環境ならDuckDBが最適解です。

ClickHouseとDuckDB――「サーバー型」vs「インプロセス型」OLAP

ClickHouseはYandexが開発し2016年にOSS化された分散型カラムナーDBで、秒間数百万行のINSERTと大規模ログ分析に特化しています。現在はClickHouse Inc.が主導し、クラウド版のClickHouse Cloudも提供されています。一方のDuckDBはインプロセス型、すなわちライブラリとしてアプリに組み込んで動かす設計で、ローカル分析と埋め込み分析に特化しています。

両者を比較する際、「どちらが速いか」という問いはあまり意味がありません。両者は想定シナリオが異なるため、単純比較には意味がないのです。「大規模リアルタイム分析」か「ローカル探索分析」か、自チームがどちらを必要としているかを整理してから選定する必要があります。

ClickHouseの特徴

ClickHouseの中核となるのはMergeTreeエンジンで、カラムナーストレージとLSMツリーに似た仕組みを組み合わせた独自実装です。秒間数百万行の書き込みを受け止めながら、数十ミリ秒で集計クエリを返すことが可能です。ログ、イベント、時系列データ、広告トラッキング、ゲームの行動ログといった大規模なイベントストリームに適しています。

以下は典型的なMergeTreeテーブルの作成SQL例です。パーティショニングとオーダーキーの設計がパフォーマンスに直結します。

CREATE TABLE events (
    event_date Date,
    user_id UInt64,
    event_type String,
    amount Float64
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id)
TTL event_date + INTERVAL 90 DAY;

DuckDBの特徴

DuckDBは「インプロセス型OLAP」で、アプリケーションと同じプロセスで動作します。インストール不要、契約不要、サーバー不要で、Pythonやブラウザ上でも動作するのが強みです。カラムナーストレージとベクトル化実行エンジンを採用し、数GB〜数十GB規模のParquetを高速にSQLで分析できます。詳細はDuckDB入門記事(B-24)をご参照ください。

本番のマルチユーザー環境やTBクラスには向きませんが、開発・CI・埋め込み分析・アドホック分析といった用途では圧倒的な導入容易性を発揮します。

徹底比較

両者の主要な観点を並べた比較表です。同じOLAPでもほぼすべての項目で性格が異なることが分かります。

観点ClickHouseDuckDB
アーキテクチャサーバー型(分散対応)インプロセス型(単一プロセス)
デプロイKubernetes / Docker / Cloudpip install / 単一バイナリ
データ量TB〜PBMB〜数十GB
同時接続多数のユーザー・クエリ1プロセス
リアルタイム性秒間数百万行の書き込みバッチ読み込み中心
学習コスト中〜高(チューニング必要)
エコシステム可視化ツール、Kafka連携等dbt、Pandas、Jupyter
料金OSS無料 / ClickHouse Cloud有料無料 / MotherDuckは有料
代表ユースケースログ分析、BI、時系列PoC、dbt開発、埋め込み分析

次にポジショニングマップで視覚的に整理します。

【ClickHouse vs DuckDB ポジショニングマップ】

  Large data
     ^
     |   [ClickHouse]
     |
     |
     |
     |
     |                           [DuckDB]
     +---------------------------------> Ease of setup
   Small data                            Instant

※ ClickHouseは大規模データ向け、デプロイには設計が必要。
※ DuckDBは小〜中規模データ向け、導入は即座。
※ 両者は対立ではなく補完関係にある。

ユースケース別の使い分け

両者の得意領域は異なるため、ユースケース別に推奨を整理しました。

ユースケース推奨理由
サービスのアクセスログ分析ClickHouse高スループット書き込みとリアルタイム集計
ゲームの行動ログ分析ClickHouse大量イベントへの耐性
リアルタイムダッシュボードClickHouse数十ms単位のクエリ応答
dbt開発環境 / PR環境DuckDBDWH費用を発生させない
ローカルでのParquet分析DuckDBインストール即実行
CI/CDのデータテストDuckDBGitHub Actionsで軽量に実行
埋め込み分析アプリDuckDB外部依存なし
広告配信ログClickHouse秒間数百万イベントに対応

ClickHouseでのリアルタイムログ集計は、たとえば次のようなクエリで実現できます。イベント流入を分単位で集計するのも、ClickHouseの得意技です。

SELECT
    toStartOfMinute(event_time) AS minute,
    count() AS events,
    uniq(user_id) AS uniq_users
FROM events
WHERE event_date = today()
GROUP BY minute
ORDER BY minute DESC
LIMIT 60;

ClickHouseの実行環境

ClickHouseを本番運用する場合、大きく3つの選択肢があります。セルフホスト、マネージドサービス、そしてClickHouse Cloudです。どれを選ぶかで運用負荷とコスト感が大きく変わります。

実行環境運用負荷コスト向くチーム
セルフホスト(K8s / VM)低〜中SREリソースあり、カスタマイズ重視
ClickHouse Cloud中〜高運用負荷を最小化したい
Altinity / Aiven等サポートと運用の両立

まとめ

ClickHouseとDuckDBは、同じOLAPでも設計思想が対照的です。本番の大規模イベントデータならClickHouse、開発とPoCならDuckDB、これが基本原則です。両者を補完的に組み合わせる(開発はDuckDB、本番はClickHouse)戦略も有効ですので、チームのフェーズに応じて柔軟に活用してください。

よくある質問

ClickHouseとDuckDBのどちらが速いですか?

大規模データ(TB以上)のサーバー環境ではClickHouseが有利、ローカルの小〜中規模データではDuckDBが手軽で高速です。用途が異なるため単純比較は不適切です。ベンチマークを見るときも「自分のワークロードに近い条件か」を必ず確認してください。

ClickHouseはリアルタイム分析に使えますか?

はい。ClickHouseはリアルタイムデータ挿入と低レイテンシクエリに特化しており、毎秒数百万行の書き込みと数十ミリ秒の集計クエリを実現できます。ログ・時系列・イベントデータの分析では最有力候補の1つです。

ClickHouseはDWH(BigQuery等)の代替になりますか?

特定のユースケース(ログ分析、リアルタイムダッシュボード)では代替可能ですが、汎用的なSQLデータウェアハウスとしてはBigQuery / Snowflakeの方がエコシステムが充実しています。得意領域を見極めたうえで役割分担するのが現実的です。