【入門編】 Query Insightsの内部構造 – Cloud Spanner

こんにちは!Cloud Spannerの世界へようこそ。
チーフアーキテクトの私です。

「世界中のどんな膨大なデータでも、止まることなく、一瞬で処理し続けるデータベース」――それがCloud Spannerです。まるで魔法のようですが、もちろん裏側には緻密で美しいエンジニアリングが隠されています。

今回は、そのSpannerの頭脳とも言える機能、「Query Insights(クエリインサイト)」の内部構造についてお話しします。

「なんだか難しそうな名前だな……」と思いましたか? 大丈夫です。専門用語はいったん脇に置いて、身近な例えを交えながら、私と一緒に優しく紐解いていきましょう。
ここをクリアすれば、Cloud Spannerの本質と付き合い方がぐっと身近になりますよ。

—

1. 例え話:超人気レストランの「厨房の記録係」

想像してください。あなたは、世界中からひっきりなしにお客さんがやってくる、超人気の巨大レストランのオーナーです。

厨房では何十人ものシェフが同時に料理を作っています。
ある日、お客さんから「今日のスープ、ちょっと味が濃かったよ」とか「注文してから出てくるまで遅かったな」という声が聞こえてきました。

さあ、オーナーであるあなたはどうしますか?
「誰が、どのレシピの、どの工程で手間取っているのか」を突き止めなければ、改善しようがありませんよね。

ここで登場するのが、厨房の専属記録係=「Query Insights」です。

記録係は、すべてのシェフの動きをずっと監視しています。

  • 「あ、今のパスタは茹でるのに時間がかかったな」
  • 「このハンバーグのレシピは、みんな何回も同じ手順を繰り返していて非効率だな」

こうした情報をこっそりノートにメモし、後で「どの料理(クエリ)に、どれくらい時間(CPUやメモリ)がかかったか」を分かりやすくまとめてあなたに報告してくれます。

Cloud SpannerにおけるQuery Insightsも、これとまったく同じことをやっているのです。

—

2. なぜQuery Insightsが必要なのか?

Cloud Spannerは、データを世界中のコンピューター(ノード)に分散して保存し、みんなで協力して超高速に処理します。

データが少なくなっているうちは、どんな書き方をしても一瞬で結果が返ってきます。しかし、システムが成長し、データが何十億行にもなると、「ちょっとした書き方の違い」で、データベースにかかる負担が何百倍も変わることがあります。

  • 「あれ? さっきまでサクサク動いていたのに、急に重くなったぞ……?」
  • 「どのプログラムがデータベースをいじめているんだ?」

そんな時、勘や当てずっぽうで探すのはエンジニアの恥です。そこでQuery Insightsを開けば、「犯人(重いクエリ)」と「その原因(非効率な実行計画)」が一発で分かるというわけです。

—

3. 内部で何が起きているのか?(3つのステップ)

Query Insightsが裏側でやっている仕事を、3つのステップで覗いてみましょう。

ステップ①:実行計画の「サンプリング」

レストランの記録係が、すべてのシェフのすべての包丁さばきを1秒も漏らさずビデオ撮影していたらどうなるでしょう? 記録係自身がパンクしてしまいますよね。

Spannerも同じです。何百万という膨大なクエリのすべてを完璧に記録しようとすると、それ自体がデータベースの負担(オーバーヘッド)になってしまいます。
そのため、Spannerは「上手にサンプリング(間引き)」をします。たくさんのクエリの中から、「お、これはちょっと時間がかかっているぞ」「リソースを多く消費しているな」というものを賢くピックアップして記録しているのです。

ステップ②:クエリの「正規化(お片付け)」

プログラムから送られてくるクエリには、次のようなものがあります。

  • クエリA:「ユーザーIDが `123` の人のデータを見せて」
  • クエリB:「ユーザーIDが `456` の人のデータを見せて」

人間から見れば「同じ質問(ユーザーを探す)」ですが、そのままにすると別のデータとして扱われ、記録ノートがごちゃごちゃになってしまいます。

そこでQuery Insightsは、数字や固有名詞を自動的に「秘密の隠しコード(プレースホルダー)」に置き換えてまとめます。
つまり、「数字違いの同じ質問は、ひとまとめにして統計を取ろう」とするのです。これを「正規化」と呼びます。これによって、「この形の質問が、今日一日でどれくらい負荷をかけたか」が綺麗に見えるようになります。

ステップ③:リソース消費との「相関分析」

ただ「時間がかかった」だけでは不十分です。Query Insightsは、そのクエリが、

  • CPUをどれくらい食べたか?
  • メモリをどれくらい圧迫したか?
  • データベースの内部でどれくらい待たされたか?

といったリソースの消費量とセットで記録します。「このクエリは、時間はそこそこだけど、CPUを異常に食いつぶしているぞ」といった立体的な分析ができるのは、この相関分析の仕組みがあるからです。

—

4. 実際の画面でどう見えるの?(イメージしてみよう)

Cloud Spannerの管理画面(Google Cloud Console)を開くと、Query Insightsのダッシュボードには次のような情報が並びます。

【Query Insights ダッシュボードのイメージ】

順位 | 正規化されたクエリの形 | 実行回数 | 平均CPU使用率 | 平均遅延時間
————————————————————————-
1 | SELECT FROM Users WHERE… | 120,400 | 🔥 高 (85%) | 0.4秒
2 | SELECT FROM Orders WHERE…| 45,200 | 中 (20%) | 0.1秒
3 | UPDATE Accounts SET… | 8,100 | 低 ( 5%) | 0.05秒

「おや、1番上の `Users` テーブルを引くクエリが、CPUをすごく食べているぞ。もしかして、インデックス(索引)が足りてなくて、テーブル全体をしらみつぶしに探している(フルスキャン)んじゃないか?」

このように、エンジニアはダッシュボードを一目見るだけで、次にどこを直せばいいのか(例:インデックスを追加する、クエリの書き方を工夫するなど)の当たりを付けることができるのです。

—

おわりに:ここをクリアすれば、もう怖くない!

いかがでしたか?
Query Insightsは、ただの「ログビューア」ではありません。いわば、巨大な分散データベースの健康状態を正確に診断し、処方箋まで教えてくれる優秀な専属ドクターです。

  • すべてを記録するのではなく、賢くサンプリングする。
  • 似た者同士の質問をきれいに正規化してまとめる。
  • 時間だけでなく、CPUやメモリなどのリソース消費と結びつけて教えてくれる。

この仕組みさえ頭に入っていれば、もし将来あなたが本番環境で「なんだかシステムが重いぞ」という場面に直面しても、慌てる必要はまったくありません。Query Insightsを開き、静かに原因を特定してスマートに解決できるはずです。

ここをクリアしたあなたなら、もうCloud Spannerの基本はバッチリマスターできていますよ!
自信を持って、次のステップへ進んでいきましょう。

コメント

タイトルとURLをコピーしました