量より『歪さ』が真の地獄。4,000万件の崩壊テーブルも億超えDBも涼しくさばくRDBの『お作法』

はじめに

AIの進化によって、データの抽出やレポート作成はとても手軽になりました。しかし、その手前にあるデータ基盤を作る技術は、今も昔も泥臭い職人技です。特に大規模なデータを扱うバックエンドの現場では、教科書通りにいかないことばかりが起きます。エンジニアなら、一度は「桁違いのデータ量」を前にして手を握り、あるいは「データ量は大したことないのに、構造が歪すぎてクエリが返ってこない」という設計の地獄に頭を抱えた経験があるはずです。今回は、経験の浅い若手エンジニアが大規模データへの恐怖を克服し、現場で涼しい顔で戦えるようになるための「ビビらないマインドと技術のお作法」をお伝えします。

本当にあった「巨大テーブル」の阿鼻叫喚

私がこれまでに直面した、2つの現場における「やばいデータベース」のリアルな状況をお話しします。

1つ目の現場は、元々ローコードツールで作成されていたアプリケーションのデータベースでした。 そのデータベースには、レコード数が4,000万件程度に達するテーブルが存在していました。データベース全体がまったく正規化されておらず、NULLを許容するカラムが大量に並ぶ歪な設計だったのです。恐ろしいことに、この設計の崩壊は4,000万件の巨大テーブルだけに留まりません。周囲にある100万件程度の別テーブルでも、全く同じ崩壊が起きていたのです。さらに、1つのカラムに複数の意味を持たせる「ダブルミーニング」の設計まで横行していました。ただ全件のフラグを1つ更新するだけでも、処理が数時間終わらない状態に陥っていました。

2つ目の現場は、さらにスケールアップした「億越えテーブル」が何個も乱立する世界が広がっていました。パフォーマンス向上のためと、意図的に正規化を崩している箇所も見受けられました。しかし、設計の意図が形骸化しており、実際の効果はほとんど薄い状態に陥っていたのです。データが巨大すぎる環境では、データの総数を知るためのSELECT COUNT(*)すら、まともに機能しません。クエリを投げても、いつまでも応答が返ってこない世界です。かろうじて日付パーティションが切られていたことだけが、唯一の救いでした。

「一発のクエリでシステム全体を止めてしまうかもしれない」というプレッシャーは、凄まじいものがあります。正体のわからない巨大なデータ量が、エンジニアを萎縮させてしまうのです。

ビビらないための処方箋1：まずは「実行計画（EXPLAIN）」を取れ

データ量に圧倒されて思考停止に陥らないために、まず絶対にやるべき鉄則があります。それは、どんなクエリを投げるよりも前に、まず「実行計画（EXPLAIN）」を取ることです。データが大きすぎてCOUNT(*)すら返ってこない世界でも、実行計画を取れば、データベースが裏側でどう動こうとしているのかが概算で分かります。どれくらいのデータにスキャンが走るのか、インデックスが使われそうかどうかが、クエリを実行する前に視覚化されます。敵の正体が数値として見えれば、恐怖は一気に半減します。「重そうなテーブルを見たら、まずはEXPLAINを打つ」という全バックエンドエンジニア共通の習慣を、自分の体へ最初に叩き込みましょう。

ただし、実行計画がいつでも100パーセント思い通りに動くとは限りません。例えば、データベース内の統計情報が古くなっていると、実行計画の予測が裏切られるケースもあります。「それなら統計情報を最新に更新しよう」と考えるのが自然な流れです。しかし、億越えテーブルともなると、統計情報の更新自体に数時間から場合によっては丸一日近くを要することもあります。統計情報の罠に正面から当たってしまった場合は、正直「どんまい」としか言えない現実もあります。泥臭い現場では、こうした予期せぬ理不尽さとも隣り合わせです。それでも、何の手がかりもないまま闇雲にクエリを流すことに比べれば、実行計画が最強の羅針盤である事実に変わりはありません。

ビビらないための処方箋2：ローカルの「100万レコード」で肌感覚を養え

大規模データにビビってしまう最大の理由は、データの「重さ」や「仕組み」を自分の感覚として理解していないからです。座学でデータベースの仕組みを100回読むよりも、遥かに効果的な近道があります。自分のローカル環境で、ダミーの「100万レコードのテーブル」を実際に作ってみてください。大量インサート文をループで回す、あるいはダミーデータ生成ツールを使うなど、やり方は何でも構いません。そうして用意したインデックスが全く貼られていない状態のテーブルに、まずは検索クエリを投げてみます。処理が詰まるもたつきを、自分のマシンを通して肌で体感するためです。

その後に、適切なインデックスを1本追加してみましょう。一瞬でクエリが爆速になるあの快感と衝撃こそが、エンジニアを大きく成長させます。ローカルの100万件で得た「インデックスの有無による挙動の差」の肌感覚は、そのまま本番環境の1億件、10億件のデータに立ち向かうための最強のマインド（自信）へと変わります。

生成AI時代だからこそ差がつく、RDBの「お作法（Sargable）」

現代の開発現場において、生成AIは心強い相棒です。複雑なクエリの組み立てをAIに手伝ってもらう機会は、確実に増えています。しかし、ここには現代ならではの大きな罠が潜んでいます。 生成AIが出力したクエリをよく見ると、実は「インデックスが全く効かない書き方」になっているケースが意外と多いのです。AIは文法的に正しいクエリを出してくれますが、テーブルの規模に応じたパフォーマンスまで完璧に考慮してくれるとは限りません。

ここで差がつくのが、エンジニア自身がRDBの「お作法」を知っているかどうかです。AIを相棒にするときは、プロンプトで「サーガブル（Sargable：インデックスを正しく利用できる条件式）な書き方を指定する」という工夫を意識しましょう。サーガブルな書き方を意識するだけで、生成AIが出すクエリの安定感は劇的に向上します。AIに丸投げするのではなく、人間がデータベースのお作法を持って手綱を握ることが、これからの時代に求められるバックエンドの職人技です。

最後に

どれだけデータ量が膨大になっても、RDBは正しい「お作法」に従って丁寧に扱えば、必ず爆速のパフォーマンスで応えてくれます。巨大なデータ量を前にビビる必要は、一切ありません。 実行計画で敵を知り、ローカルで肌感覚を養い、お作法を持ってAIを乗りこなしましょう。 難解に見えるデータ処理を涼しい顔でこなす、最高にカッコいいエンジニアへの一歩を、まずはあなたのローカルマシンの100万件から踏み出してみてください。