Google Cloud Platform

NoSQL から新しい SQL へ : グローバルなミッションクリティカル DB へと進化を遂げた Cloud Spanner

Google Cloud Spanner は先ごろ正式リリース(GA)されました。詳しくはこちらへ。

Cloud Spanner が正式リリースされ、ミッションクリティカルな本番ワークロードに使用できるようになりました。この機会に、Spanner がどのようにして、グローバルな強整合性を持つリレーショナル データベース サービスへと発展してきたかを紹介しましょう。

紹介にあたっては、Spanner チームが最近 SIGMOD '17 で発表した新しい論文を参考にしました。この論文は、Spanner の “データベース DNA” と、それが時間とともにどのように進化したのかに関する魅力的な洞察を提供しています。

Spanner はもともと、ビジネスクリティカルな大規模アプリケーションを支えるグローバルなフォールト トレラント サービスに関する Google の社内要件を満たすように設計されました。それが今では、リレーショナル データベースの SQL 機能、強い整合性ACID トランザクションといった機能も提供しています。

こうした機能は、金融トランザクションや在庫管理、アカウント認可、チケット販売 / 予約のようなビジネスクリティカルなユース ケースでは他に代わるものがありません。たとえば、「全世界における 1 つのトランザクション状態の維持」というミッションクリティカルな要件を満たす、強い整合性よりもレベルの低い “一定範囲の整合性” というものは存在しないのです。この要件を満たすのは強い整合性だけです。そのため、結果整合性データベースをクリティカルな OLTP に使用することを選ぶユーザーは、まずいません。

Cloud Spanner のユニークな機能セットは、すでに JDA、Snap、Quizlet といったお客様から反響をいただいています。

以下、上記論文のハイライトをいくつか挙げましょう。

  • Spanner は当初 NoSQL キーバリュー ストアとして設計されましたが、新たな要件に対応するためにリレーショナル モデルも採用しました。
    Spanner を担当するアーキテクトの目標は比較的限定されていました。それは、複数のデータセンターにわたってフォールト トレラントな複数行トランザクションと強整合性をサポートするサービスの提供でした(当初の Spanner は Cloud Bigtable の大きな影響下にあり、そのコード ベースの多くの部分を利用していました)。
    一方、OLTP アプリケーション開発を担当する社内顧客は、データベース スキーマ、cross-row トランザクション、表現力が豊かなクエリ言語を必要としていました。そのため、Spanner のライフサイクルの初期段階で、Spanner チームは Google の分散リレーショナル データベースである F1 の開発経験を生かし、堅牢なリレーショナル セマンティクスと SQL 機能を Spanner のアーキテクチャに統合しました。
    「こうした変更のおかげで、Spanner の巨大なスケーラビリティを保ちながら、データベース アプリケーションの強力なプラットフォームをお客様に提供できるようになりました」と著者らは論文で述べています。そして、こう付け加えています。「Google インフラストラクチャを使用しているエンジニアの観点から見ると、SQL vs. NoSQL の二分法は、もはや意味をなさないかもしれません」
  • Spanner のSQL クエリ プロセッサは、れっきとした標準規格の実装ですが、クエリのレイテンシ低減に役立つユニークな機能も備えています。
    クエリの範囲抽出(簡単に再作成できない複雑な式のランタイム分析が目的)や、クエリの再開(レイテンシに大きな影響を与えることなく、障害、リシャーディング、その他の例外から回復する)といった機能は、レイテンシの増加につながりかねない高度に分散されたクエリの複雑さを軽減します。さらにクエリ プロセッサは、低レイテンシ クエリまたは長時間クエリのトランザクション ワークロードと分析ワークロードの両方を処理します。
  • SQL ツールへの長期にわたる投資の成果として、おなじみの RDBMS ライクなユーザー エクスペリエンスを実現しました。
    社内のすべてのリレーショナル サービス(Spanner、Dremel / BigQuery、F1 など)を一般的な SQL 機能に標準化する全社的な取り組みの一環として、Spanner のユーザー エクスペリエンスでは、ANSI SQL コンストラクトに加えて、ネストされたデータを標準機能としてサポートすることに重点が置かれています。
    「SQL は、複雑なデータ アクセス パターンの表現や、コンピュータによるデータ処理において重要な付加価値を提供しています」と、著者らは論文に記しています。
  • Spanner は近いうちに、データベース ライクなアクセス パターン向けに設計された Ressi という新しいカラム フォーマットを(ハイブリッド OLAP / OLTP ワークロードに)利用するようになります。
    Ressi は、頻繁にバージョンが更新される(急速に変化する)データに最適化されており、最新の値をクエリによって効率的に検索できるようにします。Ressi は 2017 年中に、Bigtable から継承された SSTables フォーマットに取って代わります。SSTables は非常に堅牢ですが、パフォーマンスを明確に考慮して設計されているわけではありません。
著者らは、論文全体のまとめとして次のように述べています。「私たちは、Spanner を SQL システムとして構築する道のりを通じて、スケーラビリティ、管理性、ACID トランザクション、リレーショナル モデル、ネストされたデータのインデックス作成に対応したスキーマ DDL、SQL という一連の機能のマイルストーンを達成してきました」

論文の全文はこちらから参照できます。

* この投稿は米国時間 6 月 1 日、Google Cloud Platform の Justin Kestelyn によって投稿されたもの(投稿はこちら)の抄訳です。

- By Justin Kestelyn, Google Cloud Platform