ClickHouseのJSONベンチマークで分かる MongoDBとの使い分け

ClickHouseは速いだけのDBではありません。JSONを列指向で扱う設計に振り切ったことで、大きな半構造化データを保存しながら、集計も速く処理できるようにしています。

この記事では、ClickHouseのJSONベンチマークをもとに、MongoDBとどう使い分けるべきかを整理します。JSONデータをそのまま受けるだけではなく、あとから集計や分析まで見据えるなら、DB選定の考え方はかなり変わります。

この記事でわかること
– ClickHouseの新しいJSON型が何を解決するのか
– MongoDBと比較したときに差が出やすい場面
– 1B件規模のJSONベンチマークが示す読み方
– どんな用途ならClickHouseを選ぶべきか

JSONを「保存する」だけでは足りない

JSONは扱いやすい形式ですが、そのままでは分析に向きません。ネストが深い、キーが増減する、型が揺れる。この3つが重なると、アプリ側で整形するか、DB側で無理に平坦化するかの選択を迫られます。

MongoDBはドキュメント指向なので、JSONを自然に受け取れます。ここは強みです。ただし、データが増えて集計が主役になると、読み取りパターンが変わります。単発の取得ではなく、広い範囲を走査して集計する用途では、保存形式そのものが効いてきます。

ClickHouseはここに別解を出しています。JSONを文字列の塊として持つのではなく、パスごとに列として持つ発想です。つまり、よく使う項目だけを効率よく読む設計です。分析で見る列が少ないほど、この差は大きくなります。

ClickHouseの公式ブログでは、1B件のJSONドキュメントを使ったJSONBenchを公開しています。比較対象はClickHouse、MongoDB、Elasticsearch、DuckDB、PostgreSQLです。

このベンチマークで見るべき点は、単なる最高速度ではありません。注目すべきは、ストレージ効率と集計性能の両方です。

公開されている結果では、ClickHouseはMongoDBより大きく少ないストレージで済み、集計も大幅に速くなっています。公式ブログでは、特定の集計でMongoDBより数千倍速い結果が示されています。もちろん、これは分析系クエリの話です。アプリのトランザクション処理の話ではありません。

ここを混同すると判断を誤ります。MongoDBは運用系の文脈で強く、ClickHouseは分析系の文脈で強い。役割が違います。

理由は列指向です。ClickHouseはJSONの各パスを独立した列として扱えるため、必要な列だけを読みます。JSON全体を毎回展開する必要がありません。

この設計は、次のような場面で効きます。
– ログやイベントを大量に集めて集計したい
– JSONの一部のキーだけを頻繁に参照したい
– 圧縮率を上げて保存コストを下げたい
– ダッシュボードで同じ集計を何度も回したい

逆に、1件ずつの読み書きや、柔軟なドキュメント更新が中心なら、MongoDBのほうが自然です。データの持ち方が、そのまま運用のしやすさにつながります。

このベンチマークを見て「MongoDBは遅い」と結論づけるのは雑です。正しい見方は、用途の違いをはっきりさせることです。

MongoDBはアプリケーションの可変スキーマを受け止めるのが得意です。ユーザー設定、商品情報、会話履歴のように、1件ごとの形が少しずつ違うデータに向いています。

一方で、ClickHouseはその後ろにある分析層で力を発揮します。イベントを蓄積して、日次・週次で集計し、異常を見つける。こういう処理では、ドキュメントDBよりも列指向DBのほうが合理的です。

実務では、MongoDBで受けてClickHouseで分析する構成が素直です。データを一箇所に閉じ込めるより、役割分担したほうが運用しやすくなります。

次の条件が多いなら、ClickHouseのJSON型は候補になります。
– ログ、イベント、計測データを大量に扱う
– JSONの形が少しずつ変わる
– 後から集計軸が増える
– SQLで分析したい
– ストレージコストも抑えたい

この条件に当てはまるなら、まず小さなデータセットで試す価値があります。最初から全移行を考える必要はありません。まずは分析対象の一部を流し込み、クエリ速度と保存コストを確認すれば十分です。

ClickHouseのJSONベンチマークが示しているのは、JSONをどう保存するかで分析性能が変わるという事実です。MongoDBが悪いのではなく、役割が違います。

アプリの柔軟なドキュメント管理ならMongoDB。大量のJSONを集計して、速く、安く、SQLでさばきたいならClickHouse。この切り分けができると、DB選定がかなり楽になります。

JSONは「受ける」だけで終わりません。あとでどう読むかまで決めてから、保存先を選ぶべきです。