こんにちは。Cloud Spannerの世界へようこそ。
分散データベースの最高峰であり、時に「魔法のようなデータベース」と呼ばれるSpanner。その性能を最大限に引き出すための最大の関門、それが「ホットスポット」という現象です。
今日は、Spannerという巨大な図書館を例に、なぜ特定の場所に人が殺到してしまうのか、そしてそれをどうやって「エレガントに」回避するか、その極意を伝授しましょう。
—
1. Spannerの「分散」という魔法を理解する
まず、Spannerがどうやって動いているか想像してみてください。
Spannerは、データを一つところに置いておくのではなく、世界中に散らばっている小さな箱（スプリットと呼びます）に細かく切り分けて保存しています。
例えば、あなたが100万冊の蔵書を持つ図書館の館長だとしましょう。
もし、本の並べ方が「タイトル順」だったらどうなるでしょうか？ 「あ」から始まる本にばかり人が殺到して、その棚の周りだけ大混雑し、他の棚はガラガラ……。これが、データベースで言うところの「ホットスポット」です。
Spannerは賢いので、自動的に棚を分割して負荷を分散しようとしますが、あまりに特定の場所に読み書きが集中しすぎると、Spannerくんも「ちょっと待って！手が足りないよ！」と悲鳴を上げてしまうのです。
2. 「連番」という名の罠
初心者が一番やりがちなのが、IDに「1, 2, 3…」という連番や、作成日時（タイムスタンプ）をキーにしてしまうこと。
— よくある設計（これだとホットスポットになりやすい！）
CREATE TABLE Users (
UserId INT64 NOT NULL, — 1, 2, 3 と増えていく連番
Name STRING(MAX)
) PRIMARY KEY (UserId);
これ、なぜダメかわかりますか？
新しく登録されるユーザーは、常に「一番大きな数字（最新の末尾）」に書き込まれますよね。つまり、常に特定の「一番後ろの棚」だけが猛烈に忙しくなるのです。
3. ホットスポットを回避する「魔法のスパイス」
では、どうすれば混雑を回避できるのか。答えはシンプルです。「あいうえお順」というルールを捨てて、「ランダムに散らす」こと。
アプローチA：UUIDを利用する
連番の代わりに、予測不可能な「UUID（ランダムな文字列）」をキーにします。これなら、データが図書館のあらゆる棚に均等に飛び火するので、特定の場所が混雑することはありません。
— UUIDを使った設計
CREATE TABLE Users (
UserId STRING(36) NOT NULL, — UUIDならランダムに散らばる！
Name STRING(MAX)
) PRIMARY KEY (UserId);
アプローチB：キーを反転させる（ビット反転）
「どうしても数字のIDを使いたい！」という場合もありますよね。その時は、数字の並び順をあえてバラバラにする「ビット反転」というテクニックを使います。例えば、IDの先頭をランダムな数字にするだけで、書き込み先がガラリと変わります。
4. 先輩からのアドバイス：バランスが大事
勘違いしてほしくないのは、「なんでもかんでもランダムにすればいい」というわけではないということです。
データベースには「範囲検索（例：10歳から20歳のユーザーを探す）」という便利な機能があります。あまりにランダムに散らしすぎると、今度は「どこに何があるかわからない！」と、検索が遅くなってしまうのです。
ここをクリアすれば、基本はバッチリです：
- 書き込みの頻度が高いテーブルは、UUIDなどで極力「先頭をバラけさせる」。
- 読み取りがメインのテーブルは、検索しやすいようにキーを設計する。
Spannerの設計は、まさに「整理整頓」と「混雑緩和」のトレードオフです。最初は難しく感じるかもしれませんが、この「データの散らばり」を想像できるようになれば、あなたはもう立派なSpannerエンジニアの入り口に立っていますよ。
—
今日はここまで。
Spannerは、あなたの設計次第で、どんなに大きな負荷もさらりと受け流す頼もしい相棒になります。ぜひ、今のプロジェクトのキー設計を見直してみてください。
また何か壁にぶつかったら、いつでも聞きに来てくださいね。応援しています！
コメント