【入門編】 NewSQLアーキテクチャ – Cloud Spanner

やあ。Cloud Spannerという、データベース界の「究極のハイブリッド車」について興味を持ってくれたんだね。素晴らしい選択だよ。

多くのエンジニアが「RDBMS（リレーショナルデータベース）の安定感」と「NoSQLの爆速スケーラビリティ」の間で板挟みになり、夜も眠れぬ夜を過ごしてきた。Spannerは、その二つの聖杯を同時に手に入れてしまった、いわば「魔法のような道具」なんだ。

今日は、小難しい理論は一旦脇に置いて、このモンスター級データベースの正体を、君の日常の風景に例えて紐解いていこう。

—

従来のデータベースには、永遠の課題があった。

RDBMS（銀行の窓口のようなもの）： 全員と正確に数字を合わせる。でも、行列が長くなると対応が遅くなる（スケールしにくい）。
NoSQL（コンビニの棚のようなもの）： 商品をどんどん並べて、いくらでも店を広げられる。でも、店全体で「今、何がいくつあるか」を即座に把握するのは苦手（正確さが少し甘い）。

Spannerは、この二つをどうやって融合したのか。それは「地球規模の正確な時計」を持っているからなんだ。Googleが物理的に作り上げた原子時計のインフラを使い、世界中のサーバーが「今は何時何分何秒か」を完璧に同期している。

おかげで、「どこにあるどのデータも、同じタイミングで読み書きできる」という、魔法のような整合性を手に入れたんだ。

君がもし、世界中で使われるSNSを作るとしたら、ユーザーのデータが膨大になった時、どうする？普通ならサーバーを増やすけど、データの整理が追いつかなくなってパンクするよね。

Spannerは、「自動でデータを分割して、勝手に引っ越しをする」という特技を持っている。

シャーディングの自動化： データが増えてきたら、「こっちのサーバー、忙しそうだな」と判断して、データを別の空いているサーバーへ自動で移動させる。
運用者は何もしなくていい： 君がやるべきことは、ただ「データが増えたら、サーバーの数を増やすボタンを押す」ことだけ。あとはSpannerが全自動でバランスを取ってくれる。

まさに、「自動で増改築を繰り返す、終わりのない巨大ホテル」のようなものだね。

実際にCloud Spannerを使うとき、難しく考えなくていい。まずはこの3つの考え方さえあれば大丈夫だ。

Spannerは、データを並べる順番が超重要だ。電話帳で「名前」で検索するのか、「住所」で検索するのかによって、インデックスの持ち方が変わるだろう？Spannerも同じで、最初に「どうやってデータを並べるか（主キー）」を設計することが、パフォーマンスの9割を決めるんだ。

「NoSQLみたいに専用の変な言語を覚えるの？」と不安がる必要はないよ。君が今まで使ってきた、あの馴染み深いSQLがそのまま動く。

— ユーザーテーブルから特定のIDを探す、ごく普通のクエリ
SELECT FROM Users WHERE UserId = ‘user_123’;
— Cloud Spannerは、世界中のサーバーに散らばっていても、
— これを完璧な整合性で返してくる。

Spannerは「レプリカ」と呼ばれるコピーを世界各地に自動で配置する。もし、東京のデータセンターが地震で沈んだとしても、Spannerは一瞬で他の地域のサーバーに切り替わって、何事もなかったかのように動き続ける。

—

Cloud Spannerをマスターするための第一歩は、これだけ覚えておけばいい。

1. 「整合性（正確さ）」はGoogleの時計が保証してくれる。
2. 「スケール（規模）」はGoogleの自動管理が保証してくれる。
3. 君は「良いSQL」と「良いテーブル設計」に集中すればいい。

エンジニアの仕事は、本来「いかに運用で苦労するか」ではなく「いかにサービスを成長させるか」にあるはずだ。Spannerは、君をその「本質的な創造」へと解放してくれる強力な武器だよ。

どうだい？少しだけ、Cloud Spannerが身近な存在に感じられたかな。
次は実際にコンソールを触ってみよう。君の作りたい巨大な何かが、世界中で爆速で動く姿を想像するとワクワクしないか？

またいつでも聞きに来てくれ。君の挑戦を心から応援しているよ。