【入門編】データ型のマッピングと互換性 – Cloud Spanner

やあ。Cloud Spannerの世界へようこそ。
世界中の巨大なデータを一瞬で捌ききるこの「怪物」を使いこなそうとする君の挑戦を、心から歓迎するよ。

今日は、Spannerを語る上で避けては通れない「GoogleSQL」と「PostgreSQL」という、二つの異なる言語（ダイアレクト）の話をしよう。

初心者にとって、この二つのどちらを選ぶべきか、そして型はどう違うのかは、最初の関門だ。でも安心してほしい。本質さえ掴めば、実はとてもシンプルなんだ。

—

「言葉選び」が重要な理由：翻訳機を通すか、ネイティブで話すか

Cloud Spannerは、世界最強のデータベースだ。しかし、彼には「二つの顔」がある。

1. GoogleSQLダイアレクト: Spannerが生まれた時から使っている「生粋のGoogle言語」。
2. PostgreSQLダイアレクト: 世界中で愛されている「PostgreSQL」という言語。

君がもし、長年PostgreSQLを使ってきたなら、迷わず「PostgreSQLダイアレクト」を選ぶべきだ。なぜなら、これまで培ってきた知識やツールがそのまま通用するからね。逆に、Googleのクラウドエコシステムにどっぷり浸かりたいなら、GoogleSQLが最適だ。

ここで重要になるのが「データ型のマッピング」だ。

—

型の正体は「情報の容れ物」

データベースにおける「データ型」とは、「どんな荷物を入れるための箱か」を決めることだ。

例えば、「名前」を入れる箱（STRING）と、「数」を入れる箱（INT64）がある。これを間違えると、あとで大変なことになる。GoogleSQLとPostgreSQLでは、この「箱の呼び名」が少しだけ違うんだ。

主要な「箱」の対応表

—

注意すべき「落とし穴」：ここだけは気をつけて

初心者が一番つまづきやすいのは、「暗黙の変換」という現象だ。

例えば、GoogleSQLでは`STRING`と言えば万能な文字列の箱だけど、PostgreSQLダイアレクトでは`VARCHAR(n)`のように、長さを指定する文化がある。

GoogleSQLの場合: `STRING(MAX)` と書けば、どんなに長い文章でも勝手に受け止めてくれる。
PostgreSQLの場合: `VARCHAR(255)` のようにサイズを決めると、256文字目を入れた瞬間に「入りません！」とエラーが返ってくる。

「柔軟さ」を好むか、「厳格さ」を好むか。この違いを理解しておくだけで、システム設計の安定感が全く変わってくるよ。

—

実務で役立つ「型定義」のヒント

実際にテーブルを作る時、こんな風にイメージしてみてほしい。

— GoogleSQLでの定義例
CREATE TABLE Users (
UserId INT64 NOT NULL,
UserName STRING(256), — 256文字まで入る箱
) PRIMARY KEY(UserId);

— PostgreSQLダイアレクトでの定義例
CREATE TABLE Users (
UserId BIGINT NOT NULL,
UserName VARCHAR(256), — GoogleSQLと同じ意味の箱
PRIMARY KEY(UserId)
);

先輩からのアドバイス：
最初は迷うかもしれないけれど、「どちらの言語で自分の頭が整理されているか」を基準に選んでいい。Spannerというエンジンの性能は、どちらを選んでも世界最高峰だ。君のアプリケーションがどちらの「言葉」を話すのが一番心地よいか、それだけを考えて選んでごらん。

—

今日のまとめ

1. 言語選び: 既存の資産があればPostgreSQL、Googleの世界観に合わせるならGoogleSQL。
2. 型の対応: 呼び名は違えど、やっていることは「荷物の箱のサイズと種類を決めているだけ」。
3. 柔軟性: GoogleSQLの方が「大雑把に何でも入る」設定がデフォルトで、PostgreSQLの方が「厳密にルールを決める」設定になりやすい。

どうだい？少しだけSpannerが身近に感じられたかな。
データ型はデータベースの「基礎の基礎」。ここを理解した君なら、Spannerという最強の武器を使いこなす準備はバッチリだ。

またいつでも相談してくれ。次は、Spannerの真骨頂である「分散トランザクション」の世界へ案内するよ。君のエンジニアとしての旅は、まだ始まったばかりだ。