【入門編】一意性制約 – Cloud Spanner

こんにちは。Cloud Spannerの世界へようこそ。

世界中の膨大なデータを一瞬でさばき、かつ決して矛盾を許さない。そんな「最強のデータベース」であるCloud Spannerを学ぼうとしているあなたの選択は、エンジニアとして素晴らしい一歩です。

今日は、その中でも「一意性制約（Unique Constraint）」という、データの「背骨」を作るための非常に重要な仕組みについてお話しします。

—

専門用語を並べる前に、日常の例え話をしましょう。

あなたが、とある大規模なイベントの「受付システム」を作っていると想像してください。そこでは、参加者一人ひとりに「チケット番号」を配ります。

もし、「チケット番号A」を二人の人に渡してしまったらどうなるでしょう？大混乱ですよね。
「一意性制約」とは、データベースに対して「おい、この列には絶対に同じ情報を二度と入れさせるなよ！」と命令する『絶対ルール』のことです。

Cloud Spannerでは、この「重複禁止ルール」をテーブルに刻み込むことで、データの品質を鋼鉄のように守ります。

—

Cloud Spannerでこのルールを作るには、「インデックス（Index）」という機能を使います。

普通のデータベースであれば「Unique制約」という名前の機能がそのまま存在することが多いのですが、Spannerは少し考え方が違います。「インデックスを作るときに、『これは唯一無二であるべきだ』という属性（UNIQUE）を付与する」ことで一意性を担保します。

イメージとしては、「参加者全員の名簿（インデックス）を用意して、同じ番号が二つ書かれていないか、登録のたびに必ずチェックする仕組み」を構築するようなものです。

例えば、「ユーザーID（user_id）」と「メールアドレス（email）」を持つユーザーテーブルがあるとします。「メールアドレスは一人一つ」というルールを強制したい場合、以下のように書きます。

— ユーザーテーブルの作成
CREATE TABLE Users (
UserId INT64 NOT NULL,
Email STRING(255) NOT NULL,
Name STRING(MAX)
) PRIMARY KEY (UserId);

— メールアドレスに「一意性制約」を追加するインデックス
— UNIQUEキーワードを付けることで、重複を許さない名簿が作成されます
CREATE UNIQUE INDEX UsersByEmail ON Users(Email);

このコードを実行した瞬間、Spannerは裏側で「Email列に重複する値が入ろうとしたら、即座にエラーで弾く」という強力な監視体制を敷きます。

もし誰かが既に登録されているメールアドレスで登録しようとすると、Spannerは容赦なくこう返します。
`”Unique constraint violated”` （一意性制約に違反しています）

—

「なぜわざわざインデックスという別枠を作るの？」と不思議に思うかもしれません。

理由はシンプルで、「検索の速さ」と「チェックの速さ」を両立させるためです。
Spannerは地球規模の巨大なデータを扱います。もし「重複がないか」を確認するために、毎回すべてのデータを上から順に見ていたら、一秒も待てないほど遅くなってしまいますよね。

インデックス（索引）を作っておけば、Spannerは辞書を引くように一瞬で「あ、そのアドレス、もう登録されてるよ！」と見抜くことができます。一意性制約は、データの整合性を守ると同時に、実はシステムを高速化するエンジンの役割も果たしているのです。

—

さて、ここまで読んでくれたあなたは、Cloud Spannerにおいて「データのルールをどう管理するか」という本質を理解しました。

この二点さえ押さえておけば、Cloud Spannerのデータベース設計において、もっとも重要な「データの整合性」という砦を築くことができます。

データベースは、ただデータを貯める箱ではありません。データが正しくあることを保証し、利用者が安心して使える「信頼」を提供する場所です。

今日学んだことを武器に、ぜひ自分の手でテーブルを作ってみてください。エラーを恐れず、制約というルールを味方につけたとき、あなたは本当の意味で「Cloud Spannerを使いこなすエンジニア」の入り口に立っていますよ。

何か分からないことがあれば、いつでも聞きに来てくださいね。応援しています。