ClickHouseは、ロシアの検索大手Yandexが2009年から社内開発し、2016年6月にApache 2.0ライセンスでOSS化した列指向DBMSです。ウェブ解析サービスYandex.Metricaの数兆行を捌くために設計されており、単一サーバでも秒間数億行のスキャンを実現します。Cloudflare、Uber、Spotifyといった巨大トラフィック企業が観測基盤や分析基盤に採用しており、OLAP分野の主要な選択肢の一角を占めます。
この記事の目次
- 速さを成り立たせる三本柱
- Yandex社内からグローバルOSSへ
- 得意なワークロードと注意点
- 他のOLAPエンジンとの違い
- まとめ
速さを成り立たせる三本柱
ClickHouseは行ではなく列単位でデータを並べて保存します。同じ型・似た値が並ぶため圧縮効率が高く、実プロジェクトでは元データの1/10程度まで縮むケースも珍しくありません。クエリは必要な列だけを読み出すため、I/Oが原理的に少なく済みます。
もう一つの肝が、ベクトル化実行とSIMD命令の活用です。C++で書かれたエンジンが一度に数千行をまとめて処理し、AVX2/AVX-512を可能な限り使い切ります。格納エンジン MergeTree は追記中心の設計で、毎秒数十万行の取り込みを単一ノードで安定して受け止めます。「OLAPは遅い」という固定観念をひっくり返した一台と言ってよい存在です。
Yandex社内からグローバルOSSへ
誕生は2009年、Yandex.Metricaのデータ量がMyISAMでもInfiniDBでも追いつかなくなったタイミングに遡ります。Alexey Milovidov率いる社内チームが内製を決め、6年の社内運用を経て2016年6月にGitHub公開されました。OSS化と同時にCloudflareが大規模採用を表明し、欧米圏での認知が一気に広まります。
2021年9月にはYandexから分離する形でClickHouse, Inc.が設立され、$50M超の資金調達を経て商用展開を本格化。2022年にはマネージド版のClickHouse Cloudが公開され、運用負荷を抑えて使いたいユーザーの受け皿になっています。OSSとしての更新も継続しており、2024年時点で月次リリースが安定して続いている数少ないOLAP製品です。
得意なワークロードと注意点
ClickHouseが最も光るのは、巨大なログを集計して可視化するワークロードです。Cloudflareは2018年にHTTPアナリティクスをClickHouseに移し、PostgreSQL時代より100倍以上速くなったと公表しました。Uberの観測基盤や、Sentryのイベントストアなど、エンジニアリング系の事例にも事欠きません。
一方で、頻繁な単一行UPDATE/DELETEには向きません。MergeTreeの設計上、変更は新しいパートを書いてバックグラウンドでマージする仕組みのため、即時反映が要件のOLTPには別DBを併用するのが定石です。また結合の最適化はPostgreSQLやSpark SQLほど洗練されていないため、巨大テーブル同士の複雑なJOINは事前にデータモデルを工夫する必要があります。
他のOLAPエンジンとの違い
比較対象として最も多いのがGoogle BigQuery、Snowflake、そしてApache Druidです。BigQueryやSnowflakeはフルマネージドで運用ゼロという利点が大きい反面、コストが従量で膨らみやすく、オンプレや国内専用クラウドに置きたい要件には合いません。ClickHouseはOSSなのでどこでも自前で立てられます。
Apache Druidは時系列ロールアップに特化していて、ClickHouseより取り込みの一貫性に強みがありますが、運用構成が複雑です。近年はDuckDBのような組込OLAPがローカル分析の選択肢として台頭しており、「単一マシンで完結する分析はDuckDB、共有クラスタで動かす分析はClickHouse」という棲み分けが見え始めています。
まとめ
ClickHouseは、列指向×ベクトル化×C++ネイティブの組み合わせで「OLAPは遅い」常識を覆した存在です。ログや観測データを大量に飲み込んで即座に集計したい現場で、いま最初に検討すべき選択肢のひとつです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント