データベース

Spanner: 非リレーショナルワークロードに適した、他と一線を画するデータベース

2024年2月2日

Google Cloud Japan Team

※この投稿は米国時間 2024 年 1 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

Spanner は、リレーショナルワークロードと非リレーショナルワークロードの両方に適したフルマネージドのデータベースサービスで、クローバル規模の強整合性、事実上無制限のスケーリングでも保たれる高い性能、SLA が 99.999% におよぶ高い可用性を備えています。

Spanner はそのリレーショナル機能で知られていますが、汎用的な Key-Value データベースでもあり、読み取り / 書き込み API を使って非リレーショナルデータを保存、取得することが可能です。実際、Google 内部での Spanner の使用は、非リレーショナルデータ関連のものが大半を占めています。

Spanner は、同期レプリケーションおよび整合性を確保しながら、事実上無制限のスケーリングを実現するという難しい課題に応えるために Google によって開発されました。リレーショナルワークロードでは、データの読み取り時に最新バージョンを確実に取得するという特長を活かしている一方で、非リレーショナルワークロードでは、ローカルのリードレプリカからステイル読み取りを行うことがよくあります。

最近、Spanner のスループットが 50% 増加し、ノードごとのストレージが 2.5 倍（最大 10 TB）になることが発表されました。さらに、レイテンシも短縮されています。こうした機能強化によって、Spanner は NoSQL ワークロードにとってさらに魅力的な選択肢となっています。

Google 内での Spanner の使用方法

Spanner は Google フォトや Google 広告、Gmail など、Google の多数のプロジェクトで幅広く使用されており、ピーク時には 1 秒あたり合計 30 億件以上の読み取り / 書き込みリクエストに対応しています。複雑な SQL やトランザクションを使用するプロジェクトもありますが、大半のワークロードは主としてキーのルックアップを行っています。そのようなワークロードに Spanner が選ばれる理由は、パフォーマンス、カスタマイズ性、スケーラビリティに優れているからです。

NoSQL データベースとしての Spanner

Spanner は、リレーショナルセマンティクスに基づく、機能豊富な RDBMS として使用できます。このようなリレーショナル機能は、同様に高度な非リレーショナルプラットフォーム上に構築されています。たとえば、Spanner のスプリットアーキテクチャは書き込みのスケーリングを支えています。さらに、Spanner は JSON に対応しているため、通常はドキュメントデータベースが使用されるような用途も含め、幅広いユースケースに活用可能です。

よくある疑問として、昨今のデータにはなぜ強整合性が求められるのか、というものがあります。現実問題として、レガシーのデータベースから NoSQL データベースへとワークロードが移行したときにも、整合性の要件が消えることはありませんでした。それどころか、かつてデータベースによって処理されていたデータの不整合を、アプリケーションによって処理することが求められるようになっています。データサイズによってはスケーラビリティが必須要件であり、そのためにお客様がアプリケーションの複雑化を受け入れざるをえないこともありました。一方、Spanner を使えば、スケーラビリティと整合性のどちらも諦めることなく、両立することが可能です。

費用はあらゆるお客様にとって主な関心事です。Spanner は月額 $65 からという費用対効果の高い料金設定に加え、確約利用割引（CUD）によって月額 $45 まで料金を抑えることもできます（地域によって料金は異なります）。無料プランを提供している非リレーショナルデータベースも存在しますが、ほとんどのエンタープライズワークロードでは、それではリソースが圧倒的に足りないのが実情です。それを踏まえると、最安プランよりも、データベースのコストパフォーマンスのほうが重要となってきます。また、Spanner は無料試用できるほか、追加費用なしでローカルでエミュレータを使用して直接開発を行うことも可能です。

お客様の活用例

Spanner を導入済みのお客様の多くは、現在、Spanner で非リレーショナルワークロードを実行しています。以下に例を紹介します。

Uber

Uber は以前、Cassandra と Ringpop をベースとしたインフラストラクチャを使用しており、開発者の生産性の低さや、データベースおよびアプリケーションレイヤ間でのリークを伴う抽象化など、さまざまな課題を抱えていました。特に、Cassandra の整合性不足によって、開発者は「特にシステムエラーによって書き込みが失敗したときの対処策を考えなければなりませんでした。ときには、[システム] のエラーによってエンティティの不整合状態が発生し、手動での修正が必要になることも珍しくなく」、費用および運用上のオーバーヘッドが膨らんでいました。同社のエンジニアリングの道のりについては、Uber のエンジニアリングブログをご覧ください。

ShareChat

インドの大手ソーシャルメディアプラットフォームである ShareChat は、非リレーショナルワークロードを NoSQL データベースから Spanner へと移行しました。同社が特に感銘を受けたのは、移行前の NoSQL データベースと Spanner のスキーマシステムが似ていたことです。これにより、ダウンタイムゼロで移行を行うことができました。さらに、Spanner に移行することで費用の大幅削減を達成しています。

「従来の NoSQL データベースとは異なり、既存のテーブル定義やスキーマ定義を再検討することなくスケールし、複数のロケーションにわたってデータシステムの同期を保持することが可能になりました。さらに、17 のインデックスがある 120 以上のテーブルを Cloud Spanner に移行することで、30% の費用削減につながり、高い費用対効果を得ることができました。」 - ShareChat、共同創業者 / CTO、Bhanu Singh 氏

詳しくは、ShareChat の移行に関するブログ投稿をお読みください。

Niantic

大人気のモバイルゲーム Pokémon GO の制作会社である Niantic は、非リレーショナルワークロードを Cloud Datastore（非リレーショナルデータストア）から Cloud Spanner へと移行しました。Niantic のシニアスタッフソフトウェアエンジニアである James Prompanya 氏はこう語ります。「ゲームが成熟してくると、データベースのサイズと規模をさらにコントロールする必要があると考えました。また、Cloud Spanner が提供する整合性のあるインデックスが気に入っています。」Spanner の整合性の高いセカンダリインデックスのおかげで、パフォーマンスが格段に向上しました。セカンダリインデックスは、データのフィルタリングや並べ替えを要するクエリのパフォーマンスを向上させるために使用されています。一部の非リレーショナルデータベースのセカンダリインデックスは結果整合性に基づいているため、ただちに最新の状態にならず、アプリケーションのレイテンシの問題を引き起こす可能性があります。

詳しくは、Niantic に関するブログ投稿をご覧ください。

Spanner と非リレーショナルデータベースの概念の比較

では、非リレーショナルの概念が Spanner の概念にどのように対応するのかを詳しく見てみましょう。

非リレーショナル	Spanner
テーブル	テーブル
アイテム	行
属性	さまざまな方法でモデリング可能。スキーマ内で列を定義するのが、Spanner で最もイディオマティックなアプローチ最も似ているのは、JSON の列 Key-Value ペアを含むインターリーブテーブル
主キー	主キー: 複数ノード間でのデータのパーティショニングと、各ノード内でのデータの並べ替え順を決める
セカンダリインデックス	非リレーショナルのシステムは通常、以下の 2 種類のセカンダリインデックスを提供する。ローカルセカンダリインデックス: インターリーブされたセカンダリインデックスとしてモデリング可能。グローバルセカンダリインデックス: Spanner のセカンダリインデックスと同等。 Spanner では、インデックスに非キー列を格納できるため、一般的な読み取りリクエストを高速化できる。 Spanner では、すべてのインデックスが常にトランザクションとしての一貫性を持つことが重要なポイントである。
スパースなインデックス	NULL 値でインデックスをフィルタリングすることで、インデックスから NULL 行を除外できる。生成列と合わせて使用すれば、インデックスから特定の行セットを除外する確実な方法となる。
ストリーム	変更ストリーム

API

非リレーショナル	Spanner
コントロールプレーンの API（CreateTable など）	スキーマの変更
カスタムクエリ言語	SQL（ANSI SQL または PG）に FORCE_INDEX などのヒントを追加することで、インデックスの使用方法を指定できる
PutItem、BatchWriteIem	トランザクション
UpdateItem	読み取り / 書き込みトランザクション。Spanner の書き込みは常に ACID 保証を提供する。
GetItem、BatchGetItem、Query、Scan	読み取り API。最新データが不要なときは、ステイル読み取りを使ってパフォーマンスを向上させることができる。ステイル読み取りでも、以前のタイムスタンプの時点での整合性が確保される。
データ型	Spanner は、業界内の他のストレージシステムとほぼ同じスカラー型を提供している。また、サポート対象のすべての型で、動的な配列をネイティブでサポートしている。ドキュメントなどの用途には、Spanner の JSON 型を使用可能。詳しくは、Spanner のデータ型をお読みください。

さらに、Spanner には一般的な非リレーショナルデータベースに比べ、以下のようなさまざまな利点があります。

強整合性の保証: Spanner は、読み取りと書き込みにおいて常に強整合性を提供し、すべてのレプリカでデータの整合性を維持します。ネットワークのレイテンシが発生した場合、レプリカが最新でなくなる可能性がありますが、その場合は、他のレプリカが最新データを提供します。最新でないレプリカでも、過去のある時点において整合性のあるデータビューを提供します。一方、非リレーショナルデータベースの多くは、結果整合性を提供しています。つまり、すべてのレプリカでただちにデータの整合性が保証されない可能性があります。したがって、金融取引やリアルタイム更新など、強整合性が求められるアプリケーションにおいて問題が発生する可能性があります。
グローバル セカンダリ インデックス: Spanner はグローバルセカンダリインデックスをサポートしているため、セカンダリインデックスを使ってあらゆるレプリカに対してデータをクエリすることが可能です。これにより、インデックス化したデータのフィルタリングや並べ替えを要するクエリのパフォーマンスが大幅に向上します。
トランザクションのサポート: Spanner は ACID トランザクションをサポートしています。したがって、複数の書き込みはアトミックに commit されるか、中止されます。この仕組みは、データの整合性が重要なアプリケーションにおいて、同一のデータが同時に複数回更新されるような場合に必須となってきます。
クエリ言語としての SQL: Spanner は、読み取り / 書き込み API に加え、広く使用されている有名なクエリ言語である SQL もサポートしています。そのため、開発者は Spanner を簡単に習得して使用することが可能です。また、クエリの内容によっては、独自仕様の複雑な API よりも、SQL を使って記述するほうがはるかに簡単で効率が良い場合があります。
アプリケーション ロジックを単純化: Spanner の強整合性の保証や、トランザクションのサポートといった特長により、アプリケーションのロジックを単純化することが可能です。たとえば、アプリケーションで Spanner を使用すれば、アプリケーション側で調整パイプラインなどの独自メカニズムを組み込んでデータの整合性を確保する必要がなくなります。

非リレーショナルワークロードで Spanner を今すぐ試してみる

Spanner は、リレーショナルと非リレーショナルの両方のワークロードに使用可能な、汎用的なデータベースです。Spanner の基本的な概念は非リレーショナルデータベースと似ていますが、Spanner には、強整合性の保証、グローバルセカンダリインデックス、トランザクションのサポート、クエリ言語である SQL のサポートなど、さまざまな利点があります。そのため、Spanner は幅広いアプリケーションでご活用いただけます。

非リレーショナルワークロードに Spanner を使ってみることにご関心をお持ちでしたら、さっそく無料でお試しください。