DuckDB、ClickHouse、Druid、Pinot：OLAPの選び方

目次

• ランキングではなく、決定木
• 比較表
• DuckDB：サービスがいらないとき
• ClickHouse：本番の均衡点
• DruidとPinot：本当に大規模リアルタイムが必要なとき

  • Apache Druid：アドテク分析から汎用ストリーミングへ
  • Apache Pinot：探索ではなく、出すために生まれた
  • 実務のDruid vs. Pinotルール
• 実際のケースを当てはめる
• よくある質問

  • DuckDBかClickHouseか？
  • ClickHouseかDruidか、どちらを選ぶ？
  • Apache Pinot vs. Druid vs. ClickHouse、どれが優れている？
  • ClickHouseかVerticaか？
  • あとからDruidやPinotからClickHouseへ移せるか、その逆は？
• まとめ

ランキングではなく、決定木

「DuckDB vs ClickHouse vs Druid vs Pinot」という汎用比較が、はっきりさせるより混乱させがちな理由は、別々の2つの問いを1つであるかのように混ぜるからです。

問い1：サービスが必要か、ライブラリで足りるか？ DuckDBはあなたのプロセスの中で動きます。残りの3つは、ポート、ユーザー、高可用性ごと別に立ち上げるサービスです。

問い2：サービスが必要なら、優先は汎用分析か、極端な同時実行下のレイテンシか？ ClickHouseは前者向けに最適化されています。DruidとPinotは後者のために生まれました。

この2問に答えれば、木はこうなります。

1. クエリを投げるのが単一プロセス——バックエンド、ノートブック、ETLスクリプト——で、データがディスクに余裕を持って収まるか？ → DuckDB。それ以上は不要です。
2. 共有サービスが必要で、複数ソースから継続的に書き込みがあり、負荷が「増え続けるイベント表の集約」か？ → ClickHouse。一人のメイカーから中規模チームまで、圧倒的多数のプロジェクトの均衡点です。
3. 優先は探索的分析ではなく、事前定義した同じクエリを数千の同時ユーザーにミリ秒レイテンシで返し、Kafkaからのストリーミングで供給することか？ → DruidまたはPinot。しかも運用に専任がいる場合だけです。

いちばんよく見る失敗は、本能でステップ1を飛ばすこと——「ちゃんと本格的なものを立てよう」——なのに、実ボリュームの80%は1台に収まっていた、というパターンです。2つ目の失敗は頻度は低いが高い代償を払います。正当化する負荷がないままステップ3に到達し、ClickHouseがバイナリ1つで解いていた問題のために6種プロセスのクラスタを運用することになる。

比較表

	DuckDB	ClickHouse	Apache Druid	Apache Pinot
アーキテクチャ	組み込み、インプロセス、サーバーなし	分散カラム型、ノードあたり1バイナリ	分散カラム型、専用プロセス	分散カラム型、専用プロセス
最小デプロイ	ライブラリ1つ（pip install duckdb）	バイナリ1つ	プロセス種別6 + ZooKeeper + メタデータストア	Controller、Broker、Server + ZooKeeper
最適な用途	ローカル分析、ノートブック、ETL、自前のParquet/CSVをクエリするアプリのバックエンド	頻繁な集約がある本番イベント表、セルフホスト	アドホック探索とホット/コールド階層を伴うストリーミングインジェスト	ミリ秒SLAで同じ事前定義クエリを超高同時実行に出す
運用複雑さ	なし：運用対象がない	低〜中：維持するサービスがもう1つ	高：専任チームが必要	高：専任チームが必要
ストリーミングインジェスト	該当なし	良い（Kafkaエンジン、マテリアライズドビュー）	極めて良い、存在理由そのもの	極めて良い、存在理由そのもの
同時実行	低い（1プロセス）	非常に良い	良い	極めて良い、そのために設計されている
柔軟なアドホッククエリ	極めて良い	極めて良い	良い	限定的：事前に分かっているパターンで輝く
使わないとき	複数の読み書きがライブデータを共有する、または1台を超えてスケールする必要がある	数万QPSの同時実行でサブ秒レイテンシを保証する必要がある	専任SREのいない小チーム、または固定パターンなしの自由な探索が優先	専任SREのいない小チーム、またはクエリの形が絶えず変わる

セルは簡略化です。詳細は続く各節にあります。

DuckDB：サービスがいらないとき

DuckDBはアムステルダムのCWI（Centrum Wiskunde & Informatica）でMark RaasveldtとHannes Mühleisenが作り、最初の公開版は2019年のSIGMOD会議で発表されました。出発点の動機が象徴的です。RとPythonのパッケージにMonetDBを埋め込もうとして、既存の分析データベースはどれも、自分が主導権を握ると仮定せずに別プロセスの中で生きるようには設計されていないと分かった。DuckDBはまさにその隙間を埋めるために生まれました。

実務では、OLTPにおけるSQLiteの分析版です。ライブラリであり、サービスではありません。pip install duckdbすれば、PostgreSQL互換のSQL方言を持つベクトル化カラムエンジンがスクリプトの中で動きます。ディスクやURLからParquetとCSVを直接クエリし、pandasとPolarsとネイティブに統合し、開けるポートも監視するプロセスもありません。

勝つ場所: 一人、あるいは単一プロセスがクエリを投げる流れすべて。探索的データサイエンス、ノートブック、自前データだけ読めればよい小さなアプリの分析バックエンド、ファイルを変換するETLパイプライン。この負荷プロファイルでは、シンプルさで本気のライバルを見つけるのは難しい。

負ける場所、そしてそれが欠陥ではなく設計である理由: DuckDBは本質的に単一プロセスです。別マシンからの数十の同時リーダーにデータを出さず、水平スケールせず、複数ソースからの絶え間ない書き込みを同時に受ける想定ではありません。共有が必要ならMotherDuckというクラウド層がありますが、その時点でツールのカテゴリは変わっています。

もう足りないという合図: 複数のサービスが同時に書き、複数のクライアントが同時に読み、互いをブロックしない必要があるとき。そこでClickHouseに渡ります。

ClickHouse：本番の均衡点

DuckDBが「1プロセス、自分のデータ」を解くなら、ClickHouseは「1サービス、みんなのデータ」を解きます。分析が自分で回すスクリプトではなく、アプリから24時間書き込みを受け、チームや顧客のクエリに答えるものになる必要があるときの選択肢です。

カラム型アーキテクチャとスパースインデックスの全体はここでは繰り返しません——詳細は**ClickHouseとは何か、インストール方法**にあります——が、この判断のための要約はこうです。バイナリ1つ、JVMなし、必須のZooKeeperなし。同じエンジンでノートPCから数百ノードまでスケールします。

DruidとPinotに対して勝つ場所: ミリ秒SLAの超高同時実行という極端なケース以外のすべて。探索的アドホッククエリ、妥当なJOIN、専任SREのいない小チーム、低い運用コスト。「リアルタイムが必要」の圧倒的多数は実際には「分ではなく秒でデータが欲しい」という意味で、そこではClickHouseで十分すぎます。

DruidとPinotに対して負ける場所: 本当のSLAが、同一クエリの数万同時実行でミリ秒——最終ユーザー数十万が同時に叩く製品機能を想像してください——なら、かなりのチューニングなしではClickHouseが足りなくなる一方、DruidとPinotはそのプロファイルのためにゼロから設計されています。

この文脈でClickHouseを使わないとき: データが1台に収まり、クエリするのが単一プロセスなら、DuckDBに対してオーバーエンジニアリングです。Kafkaからのストリーミングで極端な同時実行のミリ秒SLAなら、DruidやPinotに対して間違った道具です。

DruidとPinot：本当に大規模リアルタイムが必要なとき

DruidとPinotは同じ家系です。どちらもJVM上で動き、システムを複数の専用プロセス種別に分け、調整にZooKeeperを依存し、Kafka型のインジェストパイプラインが絶えず流し込むことを前提にしています。どちらもClickHouseより明らかに運用が重い。意見ではなく、バイナリ1つの代わりに6種（Druid）または3種（Pinot）のプロセスを別々にデプロイ、監視、スケールする直接の帰結です。

しかし互いに置き換え可能ではありません。生まれた問題が違うからです。

Apache Druid：アドテク分析から汎用ストリーミングへ

Druidは2011年、Metamarketsの中で生まれました。プログラマティック広告の会社で、数十億イベントをリアルタイムでドリルダウンとロールアップ分析する必要があり、MySQLもHBaseも必要な速度を出せないと分かった。2012年にオープンソース化され、2015年にApacheライセンスへ移りました。

その起源——変わるディメンションと、想定外の切り方をしたいユーザーを伴う、イベントストリーム上の探索的分析——が今も設計を規定しています。Druidは「ホット」（最近、メモリ内）と「コールド」（履歴、ディープストレージ）を明示的に分け、最新だけでなく全履歴に対する探索クエリと長期保持が必要な相手に強くなります。

Pinotに対して勝つ場所: 想定外のアドホッククエリの柔軟さと、古さに応じたデータ管理。アナリストチームがインデックスを作り直さずに履歴へ新しい問いを投げたいなら、Druidの方が余地があります。

Apache Pinot：探索ではなく、出すために生まれた

PinotはLinkedInで、ずっと狭く具体的な目標から生まれました。「誰がプロフィールを見たか」のような機能を、数億ユーザーにミリ秒レイテンシで出すこと。スターツリーインデックス、転置インデックス、既知のアクセスパターン向けのパーティショニングというアーキテクチャが、同じ形のクエリを何度も何度も、非常に速く、大勢に同時に実行するよう最適化されているのは偶然ではありません。

Druidに対して勝つ場所: 事前定義クエリでの生の同時実行。出すクエリの形が事前に分かっている——固定フィルタの製品ダッシュボード、ユーザーごとのメトリクスカウンタ——かつ、最小レイテンシで数万同時クエリを支えるのが優先なら、Pinotはその一点により研ぎ澄まされています。

Druidに対して負ける場所: 新しい形の探索クエリ。Pinotはアクセスパターンを知り、それに合わせてインデックスするときに輝き、誰も予想しなかった問いが来ると窮屈です。

実務のDruid vs. Pinotルール

問題が「内部チームが自由に探索するリアルタイム分析」ならDruidへ。問題が「予測可能なクエリと超高同時実行で、最終ユーザー向けのリアルタイム分析」ならPinotへ。どちらが自分のケースかはっきりしないなら、まだどちらも要らないというかなり強い合図です。本当の問題はたぶん木のステップ3ではなくステップ2です。

どちらも使わないとき: チームが数人で、JVM上の分散システムを運用した経験がなければ、ZooKeeperで協調する6プロセスを維持するコストは、非常に大きな規模以外では回収できません。複数の有名企業がコスト削減と単純化を理由にDruidからClickHouseへ負荷を移したのは象徴的で、まさに実ボリュームがその複雑さを要求していなかったからです。

実際のケースを当てはめる

理論から下ろすために、具体的な4つのシナリオと、指し示すツールです。

ノートブックからParquetの過去売上を探索するデータアナリスト。 DuckDB。議論の余地なし。1プロセス、ノートPCに収まるデータ、誰とも状態を共有する必要ゼロ。

毎日増える製品イベント表と、数人が見る社内ダッシュボードを持つB2B SaaS。 ClickHouse。共有サービス、継続書き込み、中程度の同時実行、保証ミリ秒レイテンシは不要。

Kafkaからインプレッションを取り込み、アナリストチームが任意のディメンションでほぼリアルタイムに切り、数か月保持するアドテク基盤。 Druid。ストリーミングインジェスト、柔軟な探索、ホット/コールド階層。

「今週のあなたの統計」のような個人化メトリクスを、厳しいレイテンシSLAで数百万人の同時ユーザーに出すソーシャルネットワークや大衆向け製品。 Pinot。事前定義クエリ、極端な同時実行、事前に分かっているアクセスパターン。

シナリオが4つのどれにもはっきり当てはまらないなら、冒頭の決定木に戻ってください。正しい答えはほぼいつも、今日の問題を解くいちばん単純な選択肢であり、いちばん印象的なものではありません。

よくある質問

DuckDBかClickHouseか？

単一プロセスがクエリを投げ、データが1台に収まるならDuckDB。ノートブック、ETL、小さなアプリのバックエンド。複数ソースからの継続書き込みと複数の同時リーダーを持つ共有サービスが必要ならClickHouse。境界は性能ではなく、「ライブラリ」対「サービス」です。

ClickHouseかDruidか、どちらを選ぶ？

圧倒的多数のケースではClickHouse。運用複雑さは低く、6種プロセスに対してバイナリ1つ、汎用分析には十分すぎる性能。Druidは、ホットとコールドに対するアドホック探索付きの大規模ストリーミングインジェストが本当の負荷で、運用の専任チームがあるときに限ります。

Apache Pinot vs. Druid vs. ClickHouse、どれが優れている？

普遍的な「最良」はありません。運用複雑さの低い本番の汎用分析ならClickHouse。柔軟な探索と古さに応じたデータ管理を伴うストリーミングならDruid。ミリ秒レイテンシで事前定義クエリを超高同時実行に出すならPinot。ベンチマークではなく、負荷のパターンで選んでください。

ClickHouseかVerticaか？

見た目以上にカテゴリが違います。Verticaはプロプライエタリのカラム型MPP（限定的なコミュニティ版あり）で、ライセンス予算とDBAチームを持つ大企業向けです。ClickHouseはライセンス費用のないオープンソースで、バイナリとしてデプロイでき、契約交渉なしにセルフホストしたい小チームにはるかに合います。

あとからDruidやPinotからClickHouseへ移せるか、その逆は？

両方向とも可能ですが、自明ではありません。インジェストモデルも、それぞれのいちばん慣用的なクエリも、直コピーではありません。通例は運用コストの低いClickHouseから始め、同時実行や本当のSLAが測定できる形で要求したときだけDruidやPinotへ移すことです。先回りではありません。

まとめ

この記事の4つのツールは、それぞれ得意なことで優れています。だからこそ「どれが良い？」という問いは立て方が間違っています。DuckDBは仕事を1プロセスがするときに勝つ。ClickHouseは妥当な運用複雑さの汎用サービスが必要なときに勝つ。DruidとPinotは、ミリ秒SLAの大規模ストリーミングという極端でのみ勝ち、しかも運用する人がいる場合だけです。

今日始める大半のプロジェクトでは、データが1台に収まるあいだはDuckDBから始め、その分析を共有サービスにする必要が出たときにClickHouseへ跳ぶのが自然な道です。本当にDruidやPinotの段に到達したなら分かります。痛みが具体的で測定できるからです。「もっと大きくあるべきだ」という直感ではありません。

次がClickHouseなら、最短経路は**ClickHouseとは何か、インストール方法です。市場の残りの選択肢をもう少し詳しく見たいなら、ClickHouse代替の比較**が、この記事がリアルタイムエンジンの決定木に合わないため意図的に外したStarRocks、TimescaleDB、クラウドウェアハウスに入ります。