ClickHouseとは？列指向DBの仕組み・MergeTreeの実装からBigQueryとの使い分けまで実装者向けに解説

数十億行のアクセスログで日次集計が数分待っても返ってこない。索引を足しサマリーテーブルを夜間に作り、それでも継ぎ足しが続く。この行き詰まりの先で候補に挙がるのがClickHouseです。ただ入れてみるとUPDATEが素直に効かず、1行ずつのINSERTで警告が出て手が止まる。本記事ではストレージの粒度まで内部動作を分解し、実装で要る設計判断と採否の線引きを2026年7月時点の一次情報で整理しました。

まとめ：ClickHouseの仕組みと採用判断の結論

ClickHouseは、大量データの集計クエリのために設計された列指向のOLAPデータベース管理システムです。Yandexが自社のWeb解析基盤向けに開発し、2016年にオープンソース化されました。SQLで操作でき、オンプレミスにもクラウドにも置けます。

速さの正体は、読むデータ量を削る構造にあります。列ごとにファイルを分けるため集計に要る2〜3列だけを読み、残りの数十列にはディスクI/Oが発生しない。主キー索引は全行を指さず、8192行単位のかたまり（グラニュール）の先頭だけを持つ疎な構造で、条件に外れたかたまりごと読み飛ばす設計です。

代償もはっきりしています。更新と削除は全パートを書き換える重い処理で、訂正が頻発する業務データには向きません。1行ずつのINSERTも苦手です。採否の軸は「読み取りが集計中心か」と「書き込みが追記中心か」の2つ。どちらかが崩れるならPostgreSQLやマネージドDWHのほうが総保有コストで有利になります。

ClickHouseとは何か｜列指向データベースが集計だけを速くする理由

行指向データベースとの構造差｜集計で読み込むデータ量が桁で変わる

PostgreSQLやMySQLのような行指向のデータベースは、1行分の全カラムを連続した領域に置きます。「注文IDが12345の行を丸ごと取り出す」操作に向いた形です。

ところが分析は逆の読み方をします。「先月の全注文の金額を合計する」なら要るのは金額カラムだけなのに、行指向では隣の顧客名も住所も備考も同じページに載っている以上いっしょに読み込まれる。カラム50本のうち集計に使うのが2本なら、無駄が大半を占めます。

列指向はカラムごとに別ファイルへ格納します。金額の合計なら金額ファイルだけを順に読めばよく、他のカラムはディスク上で触れられません。副次的な効きめが圧縮率で、同じ列には似た値が並ぶため繰り返しや差分の圧縮がよく効く。読むバイト数が減れば所要時間も短くなります。

OLTPではなくOLAPへ寄せた設計と、その代わりに捨てているもの

データベースの用途は、伝票を1件ずつ登録・更新するOLTPと、大量の履歴をまとめて集計するOLAPに分かれます。ClickHouseは後者へ振り切った製品で、その処理形態の一般的な意味はOLAP（オーラップ）分析とは何か？定義と基本的な概念で扱うため、本記事はClickHouse側の動作に絞ります。

振り切った結果として手放したものは3つ。第1に行単位の即時更新、第2に複数テーブルにまたがる厳密なトランザクション、第3に1件だけを取り出す点検索の速さです。列指向では1行を復元するのにカラム数ぶんのファイルを触るため、主キー1件の取得はむしろ行指向より不利になります。

ここを踏まえず業務システムの本体を載せ替えると運用が破綻します。ClickHouseは業務データベースの置き換えではなく、その隣に置く集計専用の器と捉えてください。

Yandex発のOSSという出自と、2026年7月時点の版の位置づけ

ClickHouseはYandexが自社のWeb解析サービスのために開発し、2016年にオープンソース化されました。「数十億行を走査してレポートを返す」という自社要件から生まれた設計思想が、そのまま製品の性格になっています。現在は独立した企業体が開発を主導し、マネージドのClickHouse Cloudも提供されています。

版の付け方は西暦下2桁と月に由来する形式で、2026年7月29日時点の最新安定版は26.7系（2026年7月22日リリース）です。長期サポート版は26.3系（2026年4月）が該当し、公開情報では25.8系のサポート終了が2026年8月29日とされています。長期サポート版は概ね年2回指定されて約1年サポートされ、直近数世代のマイナーリリースも修正対象です。

既定値が版で切り替わる機能もあるため、本番では最新版を追わず長期サポート版に寄せ、年1回の更新計画を立てるほうが運用は静かになります。

MergeTreeの仕組み｜パート・マージとスパース主キーの動作

パートとバックグラウンドマージ｜追記して後から束ねる書き込み方式

実質的な標準となるテーブルエンジンがMergeTreeファミリーです。INSERTを受けると、その一括ぶんをソート済みの「パート」としてディスクへ書き出します。パートはディレクトリに対応し、その中にカラムごとのファイルが並ぶ構造。既存データを書き換えず新しいパートを足していく点が特徴です。

放っておくとパートが増え続けるため、バックグラウンドのプロセスが小さなパートを継続的にマージしてまとめます。この過程で並び順が保たれ、読み取り時に触るファイル数も減る。マージには種類があり、同じ主キーの行から最新版だけを残すもの、集計値へまとめるもの、期限切れを移動・再圧縮・削除するものがあります。

設計上の含意は、書き込みが軽く整理が後回しになる点。投入の粒度を誤るとパート数が上限に触れ、書き込みが止まる事故につながります。

スパース主キーとグラニュール｜8192行単位で読み飛ばす仕組み

MergeTreeの主キー索引は、行を1つずつ指すものではありません。パート内のデータを既定で8192行ごとの「グラニュール」に区切り、各グラニュール先頭の主キー値だけを記録する疎な索引です。索引が小さくメモリに収まりやすく、走査は「条件に合いうるグラニュールだけを読む」形になります。

B木索引が1行を特定するために働くのに対し、スパース索引は範囲を絞って読み飛ばすために働きます。1件だけを狙う検索では8192行を読んでから絞る動きです。

絞り込みを補う仕掛けも別にあります。最小最大値やSet、Bloom filterを使うスキッピング索引は、主キー以外の条件でグラニュールを除外する仕組み。異なる並び順のコピーを持つプロジェクションを定義すれば、別の切り口の集計も読み飛ばしが効きます。

ORDER BYの並び順が性能を決める｜カーディナリティの考え方

MergeTreeのテーブル定義で最初に決めるのがORDER BYです。ここで指定した順序でパート内の行が並び、その順序がそのまま主キー索引になる。つまり並び順の設計が、読み飛ばせるかどうかを決めます。

基本の指針は、値の種類が少ないカラムを先頭に、多いカラムを後ろに置くこと。先頭に一意なIDを置くと索引が全域に散らばり、どの条件でもグラニュールを除外できません。テナントIDや種別のような粗いカラムを先に置けば、その条件だけで大半が外れます。

並び順の位置	置くべきカラム	理由
先頭	種類の少ない絞り込み条件	大半を一度に除外できる
中間	時刻など範囲で切る列	期間指定で範囲を絞れる
末尾	一意に近い識別子	並びの局所性を保てる

パーティションキーは別の概念で、ディスク上のデータをまとまりに分ける指定です。月単位など粗い粒度が定石で、日単位ではパートが細分化して管理コストが跳ね上がります。削除やデータ移動をまとめたい単位に合わせてください。

圧縮コーデックの選び分け｜LZ4とZSTD、時系列データ向けの指定

ClickHouseはカラムのデータをブロック単位で圧縮して保存します。既定はLZ4で、圧縮率より展開の速さを取る選択。標準ブロックサイズは1MBです。使用量を抑えたい場合はZSTDへ切り替えられ、圧縮率が上がる一方でCPU負荷は増えます。

データの性質に合わせた専用コーデックもあります。時系列の浮動小数点値ではGorillaやFPCといった差分に着目した符号化が効く。連番や時刻のような規則性のある列では、差分を取ってから汎用圧縮をかける組み合わせが定番です。

選び分けの基準は、そのカラムをどれだけ頻繁に読むかです。集計へ使う列はLZ4のまま、長期保管するだけの列はZSTDで縮める。一律にZSTDへ寄せるとCPU時間が伸びて本末転倒になります。

書き込みと更新の実装｜バッチINSERTと重複排除・集計の設計指針

バッチINSERTが前提｜1行ずつ入れると小さなパートが溢れる

最初に踏む地雷が、アプリケーションからの1行ずつのINSERTです。INSERT1回につきパートが1つ作られるため、毎秒数百件を個別に投げるとパートが爆発的に増える。マージが追いつかず、やがて上限に触れて書き込みが拒否されます。

正攻法は、アプリケーション側で数万行から数十万行をためてから1回で投入する形。ログ収集ならKafkaやファイルを挟み、一定件数か一定時間で区切って流し込みます。

アプリ側にバッファを持てない場合の逃げ道が非同期INSERTです。サーバー側で受けた小さなINSERTを内部バッファへためてまとめて書き出す設定で、既定値は版で変わるため導入時に確認してください。応答直後に落ちると未書き出しぶんが失われる設定も選べるため、欠損を許さない用途では書き出しを待つ側を選びます。

更新と削除が苦手な理由｜ミューテーションとReplacingMergeTree

UPDATEとDELETEに相当する操作はありますが、内部では「ミューテーション」という非同期の重い処理になります。条件に合う行を含むパートを読み直して作り直す動きで、対象が1行でもパート全体が書き換え対象。しかも複数パートにまたがる処理はアトミックではなく、途中経過が見える瞬間があります。

軽量な削除は別の扱いで、内部のビットマップに印を立てるだけで実際の除去は将来のマージへ先送りされます。クエリから消えて見えてもディスク上には残ります。

訂正が日常的に発生するなら、更新文ではなくテーブルエンジン側で吸収してください。ReplacingMergeTreeなら同じ並び順キーの行はマージ時に最新の1件だけが残ります。ただし即時ではないため、クエリ側で最終行を選ぶ書き方を併用するのが実務の作法。集計値を持つならAggregatingMergeTree、期限切れの自動削除ならTTL指定と、目的別に選びます。

マテリアライズドビュー｜挿入のたびに集計を先に作っておく設計手法

ClickHouseのマテリアライズドビューは、他のデータベースの「定期的に作り直すスナップショット」とは別物です。新しいパートが挿入されるたび、その挿入ぶんだけを変換・集計して別テーブルへ書き足す増分の仕掛けになります。

日次バッチでサマリーを作る運用との違いは2つ。1つは集計結果が挿入と同時に更新され、待ち時間なしで最新値を返せること。もう1つは投入済みのデータへ遡らないため、ビューを後から足したときは過去ぶんを手動で流し込む点です。

部分集計の状態を保持し、マージのたびに結合していく形も取れます。表示項目が固まったダッシュボードなら、生ログを都度集計するより表示単位のビューを先に用意するほうが読み取り負荷は安定します。

他のOLAP製品との違い｜BigQuery・Snowflake・DuckDBとの比較

マネージドDWHとの違い｜課金モデルと運用責任をどこへ置くか

BigQueryやSnowflakeのようなマネージドDWHとの差は、性能よりも課金と運用責任の置き場所に出ます。マネージド側はスキャン量や稼働時間で課金され、サーバーの面倒は見なくて済む一方、クエリが増えるほど費用が読みにくくなる構造です。

セルフホストのClickHouseは、サーバー費用が上限として先に決まります。集計を何回投げても課金は増えず、代わりに版の更新・監視・容量計画・複製構成の責任が自社に残る。ClickHouse Cloudなら運用は預けられますが、使用量に応じた課金です。

製品としてのDWHの一般的な選び方はデータウェアハウス（DWH）とは？仕組み・製品比較・選び方で扱っています。AWS上でマネージドDWHを検討するならAmazon Redshiftとは？特徴・料金・使い方とアーキテクチャのほうが判断材料になります。

DuckDBとの違い｜プロセス内で完結するかサーバーを持つか

同じ列指向でも、DuckDBはアプリケーションのプロセス内で動く組み込み型です。サーバーを立てず、ライブラリとして読み込んで手元のファイルへ問い合わせる形。分析者が単独でCSVやParquetを集計する用途では、この手軽さが効きます。

ClickHouseはサーバーとして常駐し、複数の利用者とアプリケーションから同時に接続される前提。データを継続的に受け取り、複製を持ち、権限を分ける運用が視野に入ります。詳細はDuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いで扱っています。

1人が手元で回すならDuckDB、チームやサービスが共有し続けるならClickHouse。競合ではなく段階の違う道具です。

PostgreSQLで足りる境界と、ClickHouseへ移す判断のしきい値

既存のPostgreSQLで済む範囲は思ったより広く、数千万行程度で日次集計が数秒に収まるなら移す理由はありません。索引の追加、集計テーブル、パーティション分割で伸ばせる余地が残ります。

移行を検討する目安は3つの症状です。第1に、集計の所要時間が分単位へ入り索引を足しても改善しないとき。第2に、行数の増加ペースが年で数倍を超え、この先も止まらないとき。第3に、分析クエリの負荷が業務システムの応答を巻き添えにしているときです。

移す場合も全面移行ではなく、業務データはPostgreSQLに残し、集計対象の履歴だけをClickHouseへ複製する構成が現実的。役割を分けたうえで、業務データベース側の選定はPostgreSQLとMySQLの違いを徹底比較を判断材料にしてください。

実装の入口｜Dockerでの起動からテーブル定義・投入・レプリケーションまで

Dockerでの起動とテーブル定義｜ORDER BYを含む最小構成

手元で挙動を確かめるならコンテナが手早い。公式イメージを起動し、付属のクライアントで接続します。

docker run -d --name ch -p 8123:8123 -p 9000:9000 clickhouse/clickhouse-server
docker exec -it ch clickhouse-client

テーブル定義ではエンジン・パーティション・並び順の3点を指定します。アクセスログ想定の最小構成は次の形です。

CREATE TABLE access_log (
  event_time DateTime,
  site_id UInt32,
  path String,
  status UInt16,
  duration_ms UInt32
) ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)
ORDER BY (site_id, event_time);

site_idを先、event_timeを後に置いたのは、サイト単位で絞ってから期間で切る読み方を想定したため。月単位のパーティションは古い月をまとめて捨てる運用を見込んだ指定です。この2行が性能を決めるので、投入前に読み取りパターンを書き出してください。

データ投入と集計クエリ｜バッチ投入と非同期INSERTの使い分け

投入はまとめて行うのが原則です。ファイルからの一括読み込みか、ためた配列を1回のINSERTで送ります。

INSERT INTO access_log VALUES
  ('2026-07-29 10:00:00', 1, '/index', 200, 12),
  ('2026-07-29 10:00:01', 1, '/login', 302, 8);

集計は通常のSQLで書けます。日別の件数と平均応答時間なら次の形です。

SELECT toDate(event_time) AS d,
       count() AS reqs,
       avg(duration_ms) AS avg_ms
FROM access_log
WHERE site_id = 1 AND event_time >= '2026-07-01 00:00:00'
GROUP BY d ORDER BY d;

WHERE句に両方を書いたのは、並び順の先頭から順に条件が当たると読み飛ばしが効くためです。並び順に含まれないpathやstatusだけで絞る問い合わせが多いなら、スキッピング索引かプロジェクションを検討します。結合は複数のアルゴリズムが実装され並列ハッシュ結合も使えますが、巨大テーブル同士を頻繁に突き合わせる設計は避け、非正規化して持つほうが速くなります。

ReplicatedMergeTreeとKeeper｜複製と可用性を確保する構成

単一サーバーのまま運用すると、ディスク障害がそのままデータ損失につながります。複製を持つにはエンジンをReplicatedMergeTreeに変え、調整役のClickHouse Keeperを別に立てます。

Keeperは合意形成のためのプロセスで、複数のレプリカが同じパート集合とメタデータを持つよう複製ログを管理します。ノードは奇数台が基本で3台構成が最小の実用形。書き込みはどのレプリカでも受け付けられます。

水平分割（シャーディング）は複製とは別の話で、分散テーブルを介して全シャードへ問い合わせる構成になり難度が一段上がります。まずは単一シャード＋2〜3レプリカで始め、容量か処理量が足りなくなってから分割へ進んでください。

ClickHouseを採用してよい3条件と、見送るべき3つの場面の判断軸

採用してよい3条件｜集計中心・データ量・書き込みパターンで見る

第1の条件は、読み取りが集計中心であること。件数を数える、合計する、期間で切って傾向を見る問い合わせが主なら構造が噛み合います。ダッシュボードのバックエンド、ログ検索基盤、行動分析がここに当たります。

第2の条件は、データ量が既存のデータベースの手に余っていること。数億行を超えて増え続ける見通しがあり、集計が分単位になっているなら移す価値が出ます。数百万行なら既存構成の調整のほうが安上がりです。

第3の条件は、書き込みが追記中心であること。発生した事実を記録し続け後から書き換えないデータ、つまりログ・イベント・計測値・取引履歴のような性格なら、パートを足していくモデルと衝突しません。3条件がそろうならClickHouseは有力な選択肢です。

見送るべき3つの場面｜更新頻度・トランザクション・小規模データ

第1に、既存レコードの更新が日常的に走る場面。会員情報や在庫のように現在値を書き換え続けるデータは、ミューテーションの重さがそのまま運用の負債になります。ReplacingMergeTreeで吸収する手はありますが、更新が主な業務なら行指向のデータベースを使ってください。

第2に、複数テーブルにまたがる厳密なトランザクションが要る場面。分析側に振った設計のため、業務システムが前提とする一貫性の保証とは考え方が異なります。金銭の移動を伴う処理は業務データベースに置き、結果を分析側へ複製してください。

第3に、データがまだ小さい場面。数千万行以下で集計が数秒に収まるなら、ミドルウェアを増やす代償のほうが大きい。サーバー、監視、複製、更新計画と手数が丸ごと増えます。「将来のために」で導入すると、使わない基盤の維持だけが残ります。

ClickHouse基盤の構築を外部へ委ねるとき見積書で確かめる5項目

集計基盤を外部へ委託する場合、見積書で確かめる項目は5つです。第1に、テーブル設計（ORDER BYとパーティションの方針、想定クエリ一覧）が成果物に含まれるか。第2に、データ投入経路の実装範囲。第3に、複製とバックアップの構成と復旧手順。第4に、版の更新方針と担当。第5に、集計結果をダッシュボードやアプリケーションへ渡す部分の範囲です。

費用が膨らみやすいのは1つ目と5つ目でしょう。並び順の設計を誤ると投入後の作り直しになり、出口を欠くと「集計はできたが画面がない」状態を生みます。一創では土台から出口までをデータ分析基盤構築・MLOps構築支援として請けています。

よくある質問

ClickHouseとBigQueryはどちらを選べばよいですか？

クエリ回数が多く費用の上限を先に決めたいならClickHouse、運用の手数を持ちたくないならBigQueryです。BigQueryはスキャン量課金のため、ダッシュボードから高頻度に叩く用途では費用が読みにくい。月数回の分析ならサーバーを持たないほうが安く済みます。

ClickHouseはUPDATEやDELETEを使えますか？

使えますが、内部ではパートを書き換える非同期の重い処理で即時には反映されません。訂正が頻繁ならReplacingMergeTreeで最新行を残す設計へ寄せ、期限切れの削除はTTL指定に任せてください。1件単位の更新を前提とした実装は避けます。

ClickHouseの料金はどれくらいかかりますか？

セルフホストならソフトウェア自体は無償で、費用はサーバーとストレージ、運用工数です。マネージドのClickHouse Cloudは使用量に応じた課金で、公式の料金ページは金額を掲示せず問い合わせ導線を置く形。実額は公式ページで確認してください。

どのバージョンを本番で使うべきですか？

長期サポート版を選び、年1回の更新計画を立てる形を勧めます。2026年7月時点では26.3系が長期サポート版で、最新の安定版は26.7系です。既定値が版で変わる機能があるため、更新前に設定差分と自社クエリの検証を挟んでください。

PostgreSQLから移行するときデータはどう移しますか？

初回は一括のエクスポートと取り込み、以降は差分連携という2段構えが基本です。ClickHouse側から外部データベースを参照する仕組みもありますが、常時接続に頼ると障害の連鎖を招く。業務データは残し、集計対象の履歴だけを複製する構成が扱いやすいでしょう。

関連記事

• OLTPとは｜OLAP・DWHとの違いとHTAP・AWS DB選定を比較解説：処理形態の対比
• Amazon Athena（アテナ）とは？使い方・クエリの書き方・料金・Redshiftとの違いを解説：ファイルへ直接問い合わせる案
• PostgreSQLとMySQLの違いを徹底比較｜性能・データ型・全文検索・移行と使い分け【2026年版】：業務DB側の選定
• Snowflake Horizonとは何か？基本的な概念と利点を紹介：マネージド側の統制
• BIツールとは？できること・ダッシュボードでの可視化・選定軸を解説：集計結果の出口