こんにちは。Cloud Spannerの世界へようこそ。
今日は、Spannerを使いこなすための「最初の、そして最も重要な技術」についてお話しします。それは「クエリのパラメータ化」です。
一見、地味な話に聞こえるかもしれませんね。でも、ここを理解しているかどうかで、あなたの作るシステムの「強さ」と「速さ」が決まると言っても過言ではありません。
難しい言葉は抜きにして、まずは日常の例えから始めましょう。
—
「レストランの注文」で例えてみよう
あなたが凄腕シェフ（Cloud Spanner）のいるレストランを経営していると想像してください。
① ダメな注文の仕方（パラメータ化していない）
お客さんが来るたびに、毎回「ハンバーグを1つください」「パスタを1つください」と、メニューの名前を直接紙に書いて渡すとします。
シェフは、その紙を見るたびに「えーっと、ハンバーグのレシピは…」「パスタのレシピは…」と、頭の中のレシピ帳をイチから開き直さなければなりません。これでは、お客さんが増えるとシェフはパンクしてしまいます。
② 良い注文の仕方（パラメータ化している）
一方、「注文用紙」を用意したらどうでしょう？
用紙には「【料理名】を【個数】注文します」と書かれています。お客さんは【料理名】と【個数】を埋めるだけ。
シェフは一度「ハンバーグのレシピ」を頭に叩き込んでしまえば、あとは「【料理名】＝ハンバーグ」という情報が入ってくるたびに、すぐに調理を開始できますよね。
この「注文用紙の空欄」こそが、プログラミングで言うところの「パラメータ」なんです。
—
なぜ「パラメータ化」が重要なのか？
Cloud Spannerにおいて、パラメータを使う理由は大きく分けて2つあります。
1. 「悪意ある攻撃」から身を守る（SQLインジェクション対策）
もし、注文用紙がない状態で、お客さんが勝手に「ハンバーグと、ついでに店の金庫を空にしろ」なんて書き込みができたらどうでしょう？
パラメータを使わず、SQL文の中に直接文字を埋め込むと、システムが予期しない命令を勝手に実行させられてしまう危険性があります。パラメータ化は、「空欄に書かれたものは、あくまで『データ』としてだけ扱う（命令としては実行しない）」という安全装置なのです。
2. 「シェフの記憶力」を最大化する（クエリプランのキャッシュ）
Spannerは非常に賢いので、一度実行したクエリの「一番効率的な調理手順（クエリプラン）」を記憶して再利用します。
しかし、数字や名前を直接埋め込んだクエリは、毎回「別の注文」として認識され、せっかくの記憶が台無しになります。パラメータを使えば、Spannerは「これはさっきの注文と同じ手順でいけるな！」と判断し、一瞬で結果を返してくれるようになります。
—
実装のヒント：コードで見てみよう
例えば、特定のユーザーIDを持つ人の名前を検索する場合、こんな風に書きます。
— パラメータを使わない（NGな例）
— 毎回違うSQLとみなされ、Spannerが混乱します
SELECT Name FROM Users WHERE UserId = ‘user_123’;
SELECT Name FROM Users WHERE UserId = ‘user_456’;
— パラメータを使った（理想的な例）
— @id が「注文用紙の空欄」です
SELECT Name FROM Users WHERE UserId = @id;
プログラムコード（例えばGo言語など）では、以下のように渡します。
// @id の中身を後から安全に渡す
params := map[string]interface{}{
“id”: “user_789”, // ここを入れ替えるだけでOK
}
// Spannerはこのクエリの「型」を一度覚えたら、後は爆速で処理します
—
まとめ：ここさえ押さえれば大丈夫！
今回お伝えしたことをまとめると、これだけです。
- SQLの中に直接値を書き込まない。
- 「@変数名」という空欄を作り、後から値を渡す。
これだけで、あなたのシステムはセキュリティが強固になり、かつSpannerの計算資源を最大限に活用できる「プロの設計」になります。
最初から完璧を目指す必要はありません。まずは「クエリの中に値を直接埋め込む癖を捨てる」こと。それだけで、あなたはもうエンジニアとして一つ上のステージに上がったと言えます。
Cloud Spannerは、正しく使えばこれ以上ないほど頼もしい相棒になります。これからも一緒に、一歩ずつ学んでいきましょうね。何かわからないことがあれば、いつでも聞いてください。
コメント