Google Spanner データベースに取り組む前に準備を整える

企業が Web スケールでアプリケーションを構築し始め、世界中の何百万ものリクエストに対応できるサービスが必要になったとき、リレーショナル データベースでは十分に機能しないことがすぐに明らかになりました。

そこでAmazonやGoogleといった企業は、こうした要求に応えられる独自のデータベースを構築しました。しかし、その規模ではリレーショナルデータベースの信頼性を低下させるような機能は一切備えていませんでした。そこで生まれたのがNoSQLです。NoSQLとは、SQLを使わず、トランザクションや参照整合性を放棄した、データベースに似た代替手段の集合体です。

振り子はリレーショナルデータベースへと回帰しましたが、NoSQLデータベースは衰退していません。それは、NoSQLが大規模アクセスの問題を解決する上で有用であることが証明されただけでなく、一部のデータモデルが、自ら生み出す問題よりも多くの問題を解決してきたからです。

ドキュメントデータベースは、プログラミング言語とデータモデル間のデータの不一致を、オブジェクトリレーショナルマッピングなどの従来のソリューションよりもはるかに容易に克服できます。グラフデータベースは、リレーショナルデータベースよりもデータネットワークの保存効率が非常に高いため、データ分析の定番となっています。

それでも、多くのプログラマーやデータモデラーはリレーショナルモデルの温かみのある雰囲気を切望していました。何かが起こるはずでした。そして、その何かがNewSQLの誕生でした。

Google Spanner は、そうした NewSQL データベースの一つです。世界中に拡張可能なリレーショナルデータベースモデルを提供し、どこからでも瞬時にデータを利用できるようにします。

このソフトウェアがどのようにしてこれほど容易にスケールしつつリレーショナルデータベースとしての性能を維持しているのかは既に他の文献で説明されていますが、それはすべて原子時計の使用と、Googleが独自のネットワークを所有・管理しているという事実によるものです。原子時計はトランザクションを正しい順序に保ち、Googleのネットワークは分断が起こらないことをほぼ保証するため、グローバルな一貫性に問題はありません。

良さそうに聞こえますが、NewSQLの恩恵を受けたい一般の人が、ソフトウェアを入手してSpannerマシンのネットワークを構築するのは容易ではありません。確かに、原子時計を設置することは（知識があれば）可能で、相対性理論のような厄介な問題があれば同期を維持することも可能でしょう。しかし、Googleのような信頼性の高いネットワークを構築・運用するのは、大企業以外ではおそらく不可能でしょう。

Spanner を試してみるには、Google Cloud Platform アカウントが必要です。

これまで使ったことがなくても、AzureやAWSに慣れているなら、すぐに使いこなせるようになるでしょう。もちろん違いはありますが、それほど大きな問題にはなりません。私のノートパソコンにGoogle Cloudをセットアップするのは比較的簡単でした。特にクラウドSDKをインストールしてからは、なおさらでした。

Spannerインスタンスの設定も簡単です。新しいインスタンスを作成し、リージョン型かマルチリージョン型か、そして必要なノード数を選択するだけです。マルチリージョン型の場合、データベースは世界中に広がります。ただし、ノードのコストは急速に増加する可能性があるので注意してください。特にマルチリージョン型を選択した場合はなおさらです。Spannerのテストで、私の教育用アカウントの容量がすぐに枯渇しました。

データベースのセットアップとテーブルの設定に関しては朗報があります。グラフィカルインターフェースを使用するか、テキストウィンドウにSQLコマンドを入力するだけで、すべて非常に簡単に行えます。Googleは様々な言語（Python、Java、C#、Go、Node、PHP、Ruby）でデモプログラムを提供しており、これらは理解しやすく、すぐにアプリケーションを稼働させることができます。ただし、SQLではあるものの、期待するほど豊富な機能を備えているわけではないことに気付くでしょう。例えば、テーブル作成時に「IF EXISTS」句が使用できず、データ型の範囲も限られています。一方、Spannerには値のコレクションを格納するための配列型がありますが、その使い方はPostgresなどとは異なります。

そして、ここから問題がいくつか発生します。MySQLやPostgres（他にも高価なリレーショナルエンジンは利用可能です）を使った既に稼働中のアプリケーションをSpannerに移行したい場合、SQLテーブル定義をインターフェースやアプリケーション経由でSpannerに読み込むだけでは十分ではありません。定義言語が大きく異なるため、SQLを大幅に書き直す必要があります。

リレーショナルデータベースがほとんどのNoSQLデータベースよりもはるかに便利なのは、JOINコマンドを使ってテーブル間でデータを結合できる点です。Spannerは、UNIONやORDER BYに加え、豊富なJOINコマンドを備えています。ただし、マルチリージョンインスタンスを使用している場合は、インスタンス間でデータを結合する必要があるため、結合によってパフォーマンスが低下する可能性があるので注意してください。

様々なバックグラウンドを持つSQLプログラマにとって、Spannerの操作は馴染みがありながらも違和感を覚えるでしょう。例えば、外部キーは参照整合性を保つのに役立ち、テーブルセットを作成する際に定義されることがよくあります。Spannerにはこの概念はありません。代わりに、テーブルをインターリーブとして定義する必要があります。インターリーブとは、テーブルが「強いデータ局所性関係」を持つことを意味します。これは2つのテーブルであれば簡単に定義できますが、テーブル数が増えると複雑さが急激に増し、標準的なSQLとは明らかに異なります。整合性を保つための他のステートメント、例えば「on delete」は、親行が削除された際に子行に何が起こるかを定義しますが、慣れ親しんだ動作とは異なる可能性があります。インデックスは期待通りに動作しますが、期待通りの動作を得るには、やはりインターリーブとして定義する必要があるかもしれません。

要するに、Spannerは目指すところ、つまりプログラマーに地球規模のリレーショナルクラスタを現実的に構築する方法を提供することを実現しています。ただし、習得すべき学習曲線があり、既にSQLデータベースを使用しているアプリケーションがある場合は、Spannerへの移行に多少の苦労を強いられるでしょう。

最善の選択肢は、まずは小規模に開始し、グリーンフィールド アプリで作業するか、グローバルなリレーショナル データベースが必要になるまで試行錯誤を続けることかもしれません。

Spanner クラスターのコストを忘れないでください!®