GROUP BYが遅い本当の理由はメモリレイテンシ
原題: It's the memory latency, stupid
なぜ重要か
分析系データベースの設計競争が激化するなか、メモリレイテンシへの対処がエンジン性能の決め手になりつつある。
データベースエンジン開発のPivotLakeは2026年10月28日、GROUP BY集計のパフォーマンスがCPU使用率100%にもかかわらず低下する根本原因を解説した。現代CPUは1ナノ秒あたり4〜8命令を処理できる一方、RAMへのアクセスには50〜100nsかかり、その間CPUは400〜800命令分を待機する。大規模HashTableによるGROUP BYはこのメモリレイテンシを直撃する。
CPUの使用率が100%を示していても、実際にはほとんどの時間をメモリアクセス待ちに費やしているケースがある。Pivotの技術ブログ記事でエンジニアのMaor Kernがこの問題を丁寧に解説した。
CPUとメモリのレイテンシ差は圧倒的だ。L1キャッシュへのアクセスは約1ns、L2は3〜4ns、L3は10〜15nsと段階的に遠くなる一方、RAMは50〜100nsかかる。つまりRAMアクセス1回で、CPUは400〜800命令を処理できるだけの時間を無駄に消費する。
この問題が最も顕在化するのがGROUP BY集計だ。素直な実装では、グループキーをキーとするHashTableを使い、行ごとにルックアップと更新を繰り返す。ユニークグループ数が少なければキャッシュに収まるが、数百万規模になるとHashTableはRAMにはみ出し、ほぼすべてのアクセスが「コールドヒット」になる。CPUは常にRAM待ちとなり、使用率は100%を示しながら実効スループットは大幅に落ちる。
記事ではClickBenchが提供する「hits」データセット（9,900万行）を使い、`SELECT count(*), UserID FROM hits GROUP BY UserID`というクエリで実証している。このクエリは約1,700万件のユニークUserIDを持つため、HashTableは必然的にRAMへ溢れる。PivotのエンジンをあえてシンプルなHashMap実装に「劣化」させたコードを示し、パフォーマンス差を測定することで問題を可視化している。
解決策としてはデータを小さなチャンクに分割してキャッシュ内で処理する手法が有効で、パフォーマンスエンジニアリングにおけるキャッシュ活用率の重要性を改めて指摘している。