なぜ行指向データベースは分析で限界を迎えるのか
多くの開発者はPostgreSQLやMySQLから使い始めます。これらは、ユーザープロフィールの更新や注文処理などのトランザクション処理(OLTP)には最適です。しかし、5億行のデータに対してSELECT AVG(price) FROM salesのような集計クエリを実行しようとすると、通常ダッシュボードは固まってしまいます。私は、エンジンが平均値を計算するためだけに全行の全バイトをメモリに読み込もうとして、ディスクが悲鳴を上げ、本番環境のCPU使用率が100%に張り付く光景を何度も見てきました。
ClickHouseは、ストレージモデルを根本から覆すことでこの問題を解決します。行単位ではなく、カラム(列)単位でデータを保存するのです。クエリに「price」カラムしか必要なければ、ClickHouseはディスク上の他のデータをすべて無視します。私の経験では、このアーキテクチャによって、標準的なSQLインスタンスでは処理しきれないようなデータセットでも、クエリ時間を45秒から80ミリ秒へと劇的に短縮できます。これは、オンライン分析処理(OLAP)やリアルタイムのテレメトリのために特別に設計されています。
インストール:ClickHouseを起動する
私は通常、2つの方法でデプロイします。長期的な本番環境の安定性にはネイティブのパッケージマネージャーを、迅速なプロトタイピングにはDockerを使用します。Ubuntu 22.04や24.04を実行しているクラウド環境では、ネイティブ方式が標準的な選択肢です。
方法1:Ubuntuへのネイティブインストール
まず、公式リポジトリを追加する必要があります。ClickHouseはデフォルトのUbuntuリポジトリには含まれていないため、GPGキーを取得してソースを登録します。非推奨となったapt-keyではなく、最新のsigned-byアプローチをお勧めします。
sudo apt-get install -y apt-transport-https ca-certificates dirmngr
GNUPGHOME=$(mktemp -d)
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/clickhouse-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 8919F6BD2B48D754
echo "deb [signed-by=/usr/share/keyrings/clickhouse-keyring.gpg] https://packages.clickhouse.com/deb stable main" | sudo tee /etc/apt/sources.list.d/clickhouse.list
sudo apt-get update
sudo apt-get install -y clickhouse-server clickhouse-client
インストールの際、デフォルトユーザーのパスワード設定を求められます。空のままにしないでください。パッケージのインストールが終わったら、デーモンを起動します。
sudo service clickhouse-server start
sudo service clickhouse-server status
方法2:Docker Composeの使用
Dockerは、システムライブラリを汚さずにローカルでテストするのに最適です。また、ClickHouseが非常に敏感なulimits(リソース制限)の管理も簡単になります。docker-compose.ymlファイルを作成します。
services:
clickhouse:
image: clickhouse/clickhouse-server:latest
container_name: clickhouse-server
ports:
- "8123:8123"
- "9000:9000"
ulimits:
nofile:
soft: 262144
hard: 262144
volumes:
- ./ch_data:/var/lib/clickhouse
- ./ch_logs:/var/log/clickhouse-server
docker-compose up -dを実行すれば、高性能なノードが稼働します。
ClickHouseインスタンスの設定
設定には通常XMLを使用しますが、最新バージョンではYAMLもサポートされています。サーバー全体の設定は/etc/clickhouse-server/config.xmlに、権限やリソース割り当てはusers.xmlに記述されています。
すべてのインターフェースでのリスニング
ClickHouseはセキュリティのため、デフォルトでlocalhostのみをリッスンします。Grafanaダッシュボードや外部のバックエンドから接続するには、config.xml内の<listen_host>タグを見つけてコメントアウトを解除します。
<!-- /etc/clickhouse-server/config.xml -->
<listen_host>0.0.0.0</listen_host>
メモリ管理とOOMの防止
メモリはClickHouseが最も積極的に消費するリソースです。16GB RAMのVPSを使用している場合、制御不能になったクエリ1つでOOM Killerが発動し、データベースがクラッシュする可能性があります。users.xmlのdefaultプロファイルでハードリミットを設定し、プロセスを保護しましょう。
<!-- /etc/clickhouse-server/users.xml -->
<max_memory_usage>12000000000</max_memory_usage> <!-- 12GB制限 -->
プロのヒント:インポート前にデータをクリーニングする
データのクリーニングは、パイプラインの中で最も退屈な作業になることがよくあります。乱雑なCSVエクスポートをきれいなJSONに変換する必要があるときは、toolcraft.app/ja/tools/data/csv-to-jsonを使用しています。これは完全にブラウザ内で動作します。これにより、レコードをJSONEachRow形式に整える際、機密データがマシン外に出ることはありません。
動作確認とモニタリング
clickhouse-clientが主なインターフェースです。標準的なSQLシェルよりも高速で機能が豊富で、数十億行のメタデータを一瞬で返してくれます。
clickhouse-client --password your_password
-- データベースを作成
CREATE DATABASE itfromzero;
-- MergeTreeエンジンを使用してテーブルを作成
CREATE TABLE itfromzero.web_logs (
event_date Date,
event_time DateTime,
ip String,
url String,
status UInt16
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, url);
ここで真価を発揮するのがMergeTreeエンジンです。データを動的に自動圧縮し、10:1や時には40:1の圧縮率を達成することもあります。これにより、従来の行指向データベースと比較して、ストレージコストを大幅に削減できます。
システムヘルスのチェック
モニタリング機能はシステムテーブルに直接組み込まれています。追加のエージェントをインストールすることなく、パフォーマンスの問題を診断できます。私はこれら2つのクエリを頻繁に使用しています。
-- 現在実行中のリソース負荷が高いクエリを特定
SELECT query_id, user, elapsed, query, read_rows, formatReadableSize(read_bytes) as data_read
FROM system.processes;
-- テーブルごとの物理的なディスク使用量を確認
SELECT table, formatReadableSize(sum(bytes_on_disk)) AS total_size
FROM system.parts
WHERE active
GROUP BY table;
クエリの動作が遅いと感じたら、read_rowsカラムを確認してください。読み取りデータが多すぎる場合は、通常ORDER BYキーが非効率であることを意味します。ClickHouseでは、プライマリキーがディスク上の物理的なソート順を決定します。これを正しく設定することが、「十分に速い」から「即座に利用可能」へとステップアップするための秘訣です。
ClickHouseへの移行は、ファミリーカーからジェットエンジンに乗り換えるような感覚です。カラム指向の考え方に慣れるまで1週間ほどかかりますが、10億行を超える複雑な集計が0.05秒で終わるのを一度見てしまえば、もう元には戻れません。

