Cloud Spannerは、リレーショナルデータベースの強整合性・SQL・トランザクションと、NoSQLのような水平スケールを一台で両立する、Google Cloudのフルマネージド分散データベースです。もとはGoogleが広告や決済といった社内の基幹システムを支えるために作った仕組みで、そのマネージド版が公開されました。「リレーショナルなのにグローバルにスケールする」という触れ込みは聞くものの、Cloud SQLやBigtableとの違い、そして自社の規模で本当に必要なのかで判断が止まる技術者は多いはずです。本記事は、外部整合性を支えるTrueTimeやPaxos同期レプリケーションの仕組み、スプリット単位の水平スケールと容量モデル、リージョナル／マルチリージョンの可用性、GoogleSQLとPostgreSQL方言やエディション、gcloudで検証環境を立ててインターリーブとホットスポット回避のDDLを流すところまで、公式ドキュメントの数値を添えて実装の解像度で整理します。
まとめ：Cloud Spannerの要点と採用判断を分ける軸
先に結論を置きます。Cloud Spannerは、リレーショナルデータベースの一貫性とNoSQLの水平スケールという、従来は二者択一だった性質を両立させたデータベースです。SQLでスキーマを定義し、複数行・複数テーブルにまたがるトランザクションを、地球規模に分散した環境でも強い整合性を保ったまま実行できます。核心にあるのが、GPSと原子時計を使った分散時計TrueTimeです。
混同されやすいCloud SQLとは、狙う規模が違います。Cloud SQLはMySQLやPostgreSQLをそのままマネージドで動かす縦スケール中心の選択肢で、単一リージョンの標準的な業務システムに向きます。対してSpannerは、単一サーバーの限界を超えて水平にスケールし、複数リージョンでも強整合を保ちたい場面のためのものです。両者は競合ではなく、規模と要件で棲み分けます。
採用判断の軸は明快です。「リレーショナルの整合性とトランザクションが要る」「かつ単一DBサーバーでは容量やスループットが頭打ちになる、またはグローバルに一貫した可用性が要る」——この二つが重なるほどSpannerの価値が出ます。逆に、データもトラフィックも中規模で単一リージョンで足りるならCloud SQLが、単一キーの超高スループットならBigtableが、その都度違う切り口の分析ならBigQueryが適します。まず「Cloud SQLで収まらない規模・整合性要件か」を先に問うのが、過剰なインフラ投資を避ける順序です。
もう一つ、検討の初期に押さえておきたい条件があります。稼働率99.999%をうたうデュアルリージョン構成とマルチリージョン構成は、公式ドキュメント上ではEnterprise Plusエディションでのみ選べる構成として整理されています。つまり「グローバル分散だからSpanner」という判断は、エディションの選択だけでなく、費用の水準まで同時に決めてしまう判断でもあるのです。検証だけなら90日・10GBの無料トライアルインスタンスが用意されており、gcloudコマンド数行で手元に環境を立てられます。仕組みの理解と並行して、まず小さく動かしてスキーマ設計の勘所を確かめるのが近道です。
Cloud Spannerの定義と分散リレーショナルがGoogleから生まれた背景
Spannerを理解する近道は、それが何のために作られたかから入ることです。もとは製品ではなく、Googleが社内で広告システム（AdWords）やGoogle Playを支えるために作った分散データベースでした。2012年のOSDIで発表されたSpanner論文（Spanner: Google’s Globally-Distributed Database）が原型で、そのマネージド版が2017年にCloud Spannerとして一般提供されました。狙いは一貫していて、「リレーショナルの使い勝手を捨てずに、グローバル規模へスケールさせる」ことにあります。
リレーショナルの整合性とNoSQLの水平スケールを両立する位置づけ
データベースの分野では長く、強い整合性を持つリレーショナル（RDB）は縦にしかスケールしにくく、水平にスケールするNoSQLは整合性を緩める、というトレードオフが前提でした。Spannerはこの前提を崩し、SQL・スキーマ・二次インデックス・ACIDトランザクションといったRDBの機能を保ちながら、ノードを足して水平にスケールする設計を採ります。読者がまずつかむべきは、Spannerが「速いNoSQL」でも「大きなMySQL」でもなく、両者の良い部分を組み合わせるために別のアーキテクチャで作られた第三の選択肢だという点です。RDBとNoSQLという区分そのものの整理はデータベースの種類とDBMS・RDBとNoSQLの選び方にまとめており、リレーショナルとNoSQLの一般的な選び分けはCloud Bigtableの仕組みと採用判断でワイドカラム型NoSQLの側から対比しています。Spannerはその反対側、強整合とSQLを守る側に立ちます。
TrueTimeと外部整合性がグローバルなトランザクション順序を作る仕組み
Spannerを他の分散DBと分ける核心が、TrueTimeという分散時計です。ふつうのシステムでは、離れたサーバー同士の時計は微妙にずれるため、「どちらの書き込みが先か」を全体で一意に決めるのが困難でした。TrueTimeは、各データセンターに置いたGPS受信機と原子時計を使い、時刻を単一の値ではなく「不確実性のある区間」（最も早い時刻と最も遅い時刻の幅）として返します。Spannerはトランザクションのコミット時に、この区間が確実に過ぎ去るまでごく短い時間だけ待つ（commit-wait）ことで、時計のずれを吸収する仕組みです。結果として、地理的に分散したサーバーで並行して走るトランザクションでも、まるで一列に順番に実行したかのように振る舞う——これが外部整合性（external consistency）になります。公式のTrueTimeと外部整合性の解説は、これを「単調増加するタイムスタンプを生成し、トランザクションの順序がコミット順序と一致することを保証する」性質として説明しています。データベース理論でいう線形化可能性にあたり、分散環境でここまで強い保証を提供できる点がSpannerの技術的な支柱です。
Paxos同期レプリケーションとMVCCによるブロックしない一貫読み取り
整合性と可用性を同時に成り立たせるのが、レプリケーションと同時実行制御の仕組みです。データはスプリット（split）と呼ぶ範囲に分割され、各スプリットが複数のレプリカを持つPaxosグループを構成します。書き込みはリーダーレプリカが受け、過半数のレプリカへ同期的に複製できてはじめてコミットが確定します。一部のレプリカやゾーンが落ちても、過半数が生きていれば処理を続けられるため、可用性が保たれる設計です。読み取り側は多版型同時実行制御（MVCC）を採り、各データは複数のバージョンをタイムスタンプ付きで持ちます。これにより、読み取りは進行中の書き込みをブロックせず、逆に読み取りが書き込みを止めることもありません。読み取りには、開始前にコミット済みのデータを必ず見る強い読み取り（strong read）と、過去のタイムスタンプを指定して待ち時間を削る古い読み取り（stale read）があり、公式は迷ったら強い読み取りを選ぶ側を推奨しています。遅延に敏感で多少の古さを許せる参照系だけ、数秒程度の許容ずれを指定して逃がす——この使い分けが、レイテンシとアプリ側の複雑さのバランスを決めます。
Cloud Spannerの水平スケール・構成・SQL方言とエディション
採用を検討する段では「どこまで伸び、どんな構成が組め、既存資産をどう活かせるのか」が判断材料になります。仕組みと選択肢で押さえます。
コンピュートとストレージの分離とスプリットによる無停止の水平スケール
Spannerのスケーラビリティは、コンピュート層とストレージ層を切り離した構造に由来します。データの実体は分散ファイルシステムColossus上にあり、ノード自体はデータを持ちません。テーブルは負荷や容量に応じてスプリット単位へ自動で分割・再配置（リシャーディング）され、ノードはその処理を担当するだけです。ノードとデータが分かれているため、容量やスループットが足りなくなったらノードを追加するだけで、アプリを止めずに水平スケールできます。閑散期は逆にノードを減らせば費用を抑えられる構造です。コンピュート容量はノード（node）またはプロセッシングユニット（processing units）で表し、公式のコンピュート容量ドキュメントでは1ノード＝1000プロセッシングユニットと定義されています。1000未満なら100単位、1000以上なら1000単位またはノード単位で指定する粒度です。小さく始めて需要に合わせて伸ばせるうえ、マネージドオートスケーラーを設定すれば、この増減を負荷に追従させて自動化できます。
リージョナルとマルチリージョナル構成が決める可用性と整合性の関係
Spannerの可用性は、レプリカをどこに置くかで決まります。リージョナル・デュアルリージョン・マルチリージョン構成の公式ドキュメントによると、リージョナル構成は同一リージョン内の異なる3ゾーンへ読み書きレプリカを1つずつ置き、3つのうち2つで書き込みクォーラムを形成します。稼働率SLAは99.99%です。デュアルリージョン構成は2リージョンに計6レプリカ（各リージョンに読み書き2＋ウィットネス1）を配置し、各リージョンで最低2レプリカがクォーラム形成に必要という条件のもと、RPOゼロで99.999%に上がります。マルチリージョン構成も99.999%で、読み書きリージョン2つに加えて読み取り専用レプリカを足せます。ここで注意したいのが、デュアルリージョンとマルチリージョンはEnterprise Plusエディション向けの構成として整理されている点です。可用性を1桁上げる判断は、そのままエディションの選択でもあります。前述のTrueTimeが効くため、複数リージョンに分散しても外部整合性は崩れません。「グローバルに分散しても強整合を守る」この性質が、一般的なリードレプリカ構成や結果整合のマルチリージョンDBとSpannerを分ける決定的な差になります。
GoogleSQL・PostgreSQL方言と3つのエディションの選び分け
既存資産の活かしやすさは、SQL方言とエディションで変わります。SpannerはGoogleSQLとPostgreSQL互換という二つのSQLインターフェースを備える構成です。前者はSpanner独自の方言でBigQueryやBigtableと同系、後者は既存のPostgreSQLの知識やツールを流用でき、移行の摩擦を下げます。エディションは2024年9月からの階層型課金で、Standard・Enterprise・Enterprise Plusの3層に整理されました。エディション概要の公式ドキュメントでは、Standardがリージョナル構成とGoogleSQL・PostgreSQL・キーバリュー機能・BigQueryフェデレーション・Data Boostを、EnterpriseがSpanner Graph・全文検索・ベクトル検索（KNNとANN）・マネージドオートスケーラー・カラムナーエンジンを、Enterprise Plusがデュアルリージョンとマルチリージョン、ジオパーティショニングを担当する形で整理されています。増分バックアップもEnterprise以上です。エディションの切り替えは無停止で10分程度とされており、後から上げる前提で小さく始める選択も取れます。なおSpannerのリリースノートでは、カラムナーエンジンのGAが2026年4月17日、PostgreSQL方言でのベクトルインデックスとANNのGAが2026年5月4日、Cassandra互換エンドポイントのGAが2025年9月25日と記録されています。必要な機能と可用性の水準から、下位エディションで足りるかを見極めるのが費用配分の勘所です。
gcloudとDDLで動かすCloud Spannerの検証環境構築の手順
仕様を読んで判断が付かないときは、先に動かすほうが早く終わります。Spannerには無料トライアルインスタンスがあり、gcloudコマンドで作成からDDL投入、クエリ実行までを数分で通せます。
無料トライアルインスタンスの90日10GB制限と検証環境の作り方
無料トライアルインスタンスの公式ドキュメントには、検証にそのまま使える条件が数値で書かれています。期間は作成から90日で、その後30日のリカバリー期間が付きます。ストレージは10GB、リージョナル構成のみで、デュアルリージョンとマルチリージョンは選べません。性能はベストプラクティスに沿った場合で読み取り毎秒500クエリ前後、1KBの単一行書き込みで毎秒100クエリ前後が目安とされています。数量の制限も明確で、プロジェクトのライフサイクルにつき1インスタンス、Cloud請求先アカウントあたり最大5インスタンス、1インスタンスあたり最大5データベースまでです。バックアップ・CMEK・Data Boost・グラフアルゴリズムは対象外なので、これらの検証には有料インスタンスが要ります。裏返せば、主キー設計の良し悪しやクエリプラン、インターリーブの効き方といったスキーマ設計の検証は、無料枠の範囲で十分に回せます。
gcloudでインスタンスとデータベースを作る最小コマンドの組み立て
インスタンス作成はインスタンスの作成と管理に載っているフラグの組み合わせで決まります。最小構成はエディション・インスタンス構成・容量の3点です。東京リージョンにStandardエディションで100プロセッシングユニットのインスタンスを立て、データベースを作るところまでは次の形になります。
gcloud spanner instances create demo-spanner \
--edition=STANDARD \
--config=regional-asia-northeast1 \
--description="Demo Instance" \
--processing-units=100
gcloud spanner databases create shopdb --instance=demo-spanner容量をノードで指定するなら --processing-units=100 を --nodes=1 に置き換えます（1ノード＝1000プロセッシングユニット）。負荷に追従させたい場合は、固定容量のフラグを外して --autoscaling-min-processing-units と --autoscaling-max-processing-units、CPU目標の --autoscaling-high-priority-cpu-target を指定する形に切り替えます。オートスケーラーはEnterprise以上の機能なので、Standardで立てた検証用インスタンスでは固定容量のまま進めるのが手堅い進め方です。
インターリーブで親子テーブルを束ねるDDLと7階層までの構造上限
Spannerのスキーマ設計で最初に決めるのが、親子関係をインターリーブで物理的に近づけるかどうかです。スキーマとデータモデルの公式ドキュメントによると、インターリーブされた親子関係の階層は最大7階層まで定義でき、子テーブルの主キーは親テーブルの主キー全体を先頭に含む必要があります。注文と注文明細のように必ずセットで読むデータでは、親子が同じスプリットに寄るため、結合のコストと読み取りのレイテンシが下がります。顧客と注文を例にした場合のDDLは、次の通りです。
CREATE TABLE Customers (
CustomerId UUID DEFAULT (NEW_UUID()),
CreatedAt TIMESTAMP NOT NULL,
Name STRING(256),
) PRIMARY KEY (CustomerId);
CREATE TABLE Orders (
CustomerId UUID NOT NULL,
OrderId INT64 NOT NULL,
OrderedAt TIMESTAMP NOT NULL,
) PRIMARY KEY (CustomerId, OrderId),
INTERLEAVE IN PARENT Customers ON DELETE CASCADE;ここで一度立ち止まる価値があります。公式ドキュメントは「テーブルをインターリーブしたら、それは永続的です」と明記しており、後から解除できません。親子を常に一緒に読むのか、それとも子テーブル単独で広く検索するのかを、DDLを書く前に確定させてください。ファイルにまとめたDDLは gcloud spanner databases ddl update で流し込め、確認のクエリは gcloud spanner databases execute-sql で実行できます。テーブル設計そのものの考え方は三層スキーマから見るデータベース設計の実務で整理しています。
ホットスポットを起こさない主キーをUUIDとシャードIDで書き分け
Spannerで最も多い失敗が、主キー設計に起因するホットスポットです。データは主キーの順序でスプリットに分割されるため、連番IDやタイムスタンプをそのまま主キーの先頭に置くと、書き込みが常に末尾の同じスプリット（＝同じノード）へ集中し、水平スケールの効果が出ません。スキーマ設計のベストプラクティスは、書き込みレートの高いテーブルで単調増加・単調減少する列を第1キーにしないよう明記したうえで、回避策を具体的に示しています。
- バージョン4のUUIDを主キーにする（GoogleSQLなら
NEW_UUID()、PostgreSQL方言ならgen_random_uuid()を既定値にする） - キーの順序を入れ替え、分散する値（ユーザーIDなど）を先頭、タイムスタンプを後ろに置く
- ビット反転シーケンスで整数キーの単調増加を崩す
- 生成列でシャードIDを作り、ハッシュで書き込みを複数スプリットへ散らす
- 高書き込みレートの単調増加列に、インターリーブしていない二次インデックスを張らない
優先順位を付けるなら、まずUUIDかキー順序の入れ替えで足ります。それでも捌けないときにハッシュシャーディングを入れる、という順です。シャード数Nは予想ノード数と同程度に置くのが公式の目安で、物理サーバー数を超える大きな値にしても効果は出ません。アクセスログのように書き込みが時刻に偏るテーブルなら、生成列を使ってこう書きます。
CREATE TABLE AccessLogs (
ShardId INT64 NOT NULL
AS (MOD(FARM_FINGERPRINT(CAST(LastAccess AS STRING)), 2048)) STORED,
LastAccess TIMESTAMP NOT NULL,
UserId INT64 NOT NULL,
) PRIMARY KEY (ShardId, LastAccess, UserId);最新順で読むことが分かっているなら、タイムスタンプ列に DESC を付けて降順で保持する手もあります。設計時点の一手が、後々のレイテンシとノード費用に直結する点がSpanner運用の要になります。
Cloud SpannerとCloud SQL・Bigtableなど他DBとの使い分け
Spannerの採用で最も多い誤解が、Cloud SQLや他のマネージドDBとの混同です。役割の違いを具体で切り分けます。
Cloud SQLとの住み分けは規模と強整合・グローバル分散の要否
SpannerとCloud SQLは、どちらもSQLを話すリレーショナルDBですが、狙う規模が違います。Cloud SQLはMySQL・PostgreSQL・SQL Serverをマネージドで動かすサービスで、基本は単一サーバーを縦にスケール（CPUやメモリを増やす）させて使う形です。単一リージョンの標準的な業務システムやWebアプリなら、Cloud SQLの方が安く、運用も慣れた形で回せます。Spannerが要るのは、その縦スケールが頭打ちになる規模か、複数リージョンにまたがって強整合を保ちたい要件が出てきたときです。判断の目安はこうです。「単一のPostgreSQLインスタンスで捌き切れるか」がイエスならCloud SQL、書き込みスループットや容量が単一サーバーの限界を超える、あるいはグローバルに一貫したトランザクションが要るならSpanner、という順序で検討します。最初からSpannerを選ぶと、小規模では明らかに過剰投資になります。
Bigtable・Aurora・Cosmos DBとの比較で見るSpannerの立ち位置
マネージドDBは製品ごとに役割が分かれます。整理すると次の通りです。
| 製品 | 種別 | 向く場面 | 苦手 |
|---|---|---|---|
| Cloud Spanner | 分散リレーショナル | グローバル規模で強整合とSQL | 小規模には過剰なコスト |
| Cloud SQL | マネージドRDB | 単一リージョンの業務システム | 単一サーバー超の水平スケール |
| Cloud Bigtable | ワイドカラムNoSQL | 単一キーの高スループット時系列 | 複数条件検索・結合・SQL |
| BigQuery | 分析DWH | 大量データのアドホック集計 | 1件を低遅延で返す運用系 |
同じGoogle Cloud内では、単一キーで大量の読み書きをさばく用途はワイドカラム型NoSQLのCloud Bigtableの領分で、SQLや結合、複数行トランザクションが要るならSpannerに寄せます。他クラウドの近い製品としては、AWSのマネージドリレーショナルであるAmazon Auroraの仕組みと料金モデルが挙がりますが、Auroraが単一リージョンでの高性能なMySQL/PostgreSQL互換に主眼を置くのに対し、Spannerは複数リージョンでの強整合と無停止の水平スケールに踏み込む点で立ち位置が分かれます。Azure Cosmos DBは整合性レベルを5段階から選ばせる設計で、強整合を既定とするSpannerとは思想が逆です。この違いはグローバル分散と強整合をどこまで求めるかで決まる分岐点になります。
Cloud Spannerの容量計画と料金構造で費用を膨らませない設計
Spannerの費用は、容量計画とエディション選択でほぼ決まります。ここは判断が分かれるので具体で示します。
コンピュート×時間×レプリカ＋ストレージの課金構造とエディション選択
Spannerの料金は、大きく三つの合算です。第一にコンピュート（プロセッシングユニット数×時間単価×レプリカ数）、第二にストレージ量、第三にバックアップとネットワークになります。押さえておきたいのは、コンピュートもストレージもレプリカ単位で課金される点です。デュアルリージョンなら6レプリカ、マルチリージョンなら読み書き4レプリカに読み取り専用レプリカが乗るため、同じプロセッシングユニット数でもリージョナル構成の数倍になります。「マルチリージョンにすると高い」のではなく、レプリカが増えた分だけ正直に増える構造だと理解すると見積りがぶれません。単価はリージョン・エディション・時期で改定されるため、金額は公式のSpanner pricingで確認してください（本記事では単価を断定しません）。費用計画の勘所は、必要な機能から逆算してエディションを選ぶことです。Spanner Graphやベクトル検索機能を使わず、リージョナル構成で足りるならStandardで収まり、上位エディションの費用を避けられます。運用に踏み込む段では、外部データセットや変更ストリームで分析基盤へ渡す側を扱ったCloud SpannerとBigQueryの連携方法もあわせて参照できます。
ストレージ上限とCPU使用率の目安から容量を逆算する見積り手順
プロセッシングユニット数は、性能だけでなくストレージ上限も決めます。公式のコンピュート容量ドキュメントによれば、1000プロセッシングユニット未満のインスタンスは100プロセッシングユニットあたり1024.0GiB、1ノード以上のインスタンスはノードあたり10TiBが上限です。300GB程度のデータベースなら100プロセッシングユニットで収まる計算になり、ここから逆算すれば最小構成の見当が付きます。サーバー数の内訳も公開されていて、リージョナル構成はノードあたり最低3サーバー、マルチリージョン構成はノードあたり最低5サーバーです。
もう一つの軸がCPU使用率です。スケールダウンの判断基準として、リージョナルインスタンスは65%未満、マルチリージョンインスタンスは各リージョンで45%未満が目安として示されています。この差はクォーラムの持ち方から来るもので、マルチリージョンでは片側リージョンの障害を吸収する余力を残す必要があるためです。見積りの手順はこうです。まずデータ量からストレージ上限を満たす最小容量を出し、次にピーク時のCPU使用率が目安を超えないかを見て、足りなければプロセッシングユニットを足す。波が大きいワークロードなら、Enterprise以上のマネージドオートスケーラーで下限と上限を決め、ピーク固定の無駄を削ります。
Cloud Spannerを採用すべき企業と別のデータベースが適する企業の条件
ここは立場を明確にします。Spannerは強力ですが、万能ではありません。要件との相性で採否がはっきり分かれます。
Cloud Spannerの投資が見合うグローバル規模・強整合・水平スケールの要件
次の条件が重なるほど、Spannerの価値が出ます。
- リレーショナルの強整合・SQL・複数行トランザクションが要り、かつ単一DBサーバーの容量やスループットでは頭打ちになる
- 複数リージョンにまたがって、一貫したトランザクションと高い可用性（リージョン障害への耐性）を同時に求める
- トラフィックの成長やスパイクが読みにくく、無停止でスケールさせたい
この条件が揃う典型が、グローバルに展開する決済・金融・在庫・広告の基盤や、利用者が世界中に散らばる大規模SaaSのマルチテナントデータベースです。単一のRDBをシャーディング（手動でDBを分割）して無理に伸ばしてきた組織が、その運用負荷とデータ整合の難しさから解放される目的でSpannerへ寄せる、という移行も現実的な動機になります。ただし移行の成否は、前述の主キー設計とインターリーブをどこまで作り直せるかで決まります。既存スキーマをそのまま載せ替える計画になっているなら、そこは要注意です。Google Cloudを軸にした大規模データ基盤の設計・実装・移行は、クラウドインフラ構築（AWS・Google Cloud・Azure）で対応しています。
Cloud Spannerを選ぶべきでない小規模・単一リージョン・単純KV・分析用途
逆に、次の場合はSpannerを選ぶべきではありません。第一に、データ量もトラフィックも中規模までで、単一リージョンで足りる構成です。Spannerは最小構成でも一定のコンピュート費用が常時かかり、この規模ではCloud SQLの方が安く、運用も慣れた形で軽く済みます。標準的な業務システムやWebアプリの多くはこちらに当てはまります。第二に、単一キーでの超高スループットな読み書きが主役で、SQLや結合を必要としない用途です。時系列やIoT、監視メトリクスのようなデータは、リレーショナルの機能を持つSpannerより、それに特化したBigtableの方が費用対効果で勝ります。第三に、その都度違う切り口で大量データを集計するアドホック分析です。カラムナーエンジンのGAで運用データへの分析クエリは速くなりましたが、DWHの代替になったわけではなく、フルスキャンのOLAPはBigQueryの領域のままです。まず要件を「強整合・グローバル分散・単一サーバー超えの規模」の物差しで測り、一つも当てはまらないなら、より軽いマネージドDBを先に検討する。この順序が過剰投資と設計のやり直しを防ぎます。なお、Google Cloudの外（オンプレミスや他社クラウド）に同じエンジンを置く必要がある場合は、ダウンロード版のSpanner Omniの導入手順・要件・エディションと採用判断が選択肢になります。
Cloud Spannerの仕組み・料金・使い分けについてのよくある質問
検討段階でよく挙がる質問をまとめます。概念と採用判断に絞って答えます。
Cloud SpannerとCloud SQLの違いは何ですか？
狙う規模が違います。Cloud SQLはMySQLやPostgreSQLを単一サーバーでマネージド運用する縦スケール中心のサービスで、単一リージョンの標準的な業務システムに向きます。Spannerはノードを足して水平にスケールし、複数リージョンでも強整合を保つ分散リレーショナルDBです。単一サーバーで捌けるならCloud SQL、その限界を超える規模やグローバルに一貫したトランザクションが要るならSpanner、という順序で選びます。小規模で最初からSpannerを選ぶと過剰投資になります。Google Cloudへの固定を外したい場合は、自己ホストもできるTiDBとは？MySQL互換の分散SQLの仕組みと採用判断の解説を比較対象に加えてください。
Cloud SpannerはNoSQLですか、リレーショナルですか？
リレーショナルデータベースです。SQL・スキーマ・二次インデックス・複数行のACIDトランザクションを備えます。NoSQLと混同されがちなのは、水平スケールという従来リレーショナルが苦手だった性質を持つためですが、整合性やSQLを緩めているわけではありません。むしろ、RDBの整合性を保ったまま水平スケールを実現した点が特徴で、単一キー中心のワイドカラム型NoSQLであるBigtableとは種別が異なります。機能追加を伴うエディション拡張でグラフ・全文検索・ベクトル検索も1つのDBで扱えるようになり、マルチモデル寄りの性格も併せ持ちます。
TrueTimeとは何で、なぜ必要なのですか？
TrueTimeは、GPSと原子時計に基づく分散時計で、時刻を単一値ではなく不確実性のある区間として返すAPIです。分散したサーバー間では時計が微妙にずれるため、「どの書き込みが先か」を全体で一意に決めるのが難しいという問題があります。Spannerはコミット時にこの不確実性区間が過ぎるまでごく短く待つことで、地理的に離れたトランザクションでも一列に順序づけられた（外部整合性のある）振る舞いを保証します。これがグローバルな強整合を成り立たせる土台です。
Cloud Spannerの料金はどのように決まりますか？
コンピュート（プロセッシングユニット数×時間単価×レプリカ数）、ストレージ量、バックアップとネットワークの合算で決まります。コンピュートもストレージもレプリカ単位の課金なので、デュアルリージョンの6レプリカ構成はリージョナルの3レプリカ構成より大きく増えます。単価はリージョン・エディション（Standard／Enterprise／Enterprise Plus）・時期で変わるため、正確な金額は公式のSpanner pricingで確認してください。波のあるワークロードではマネージドオートスケーラーでプロセッシングユニットの無駄を抑えるのが定石です。
Cloud Spannerで既存のPostgreSQLアプリは動きますか？
PostgreSQL互換インターフェースが用意されており、既存のPostgreSQLの知識やツール、SQLをある程度流用して移行の摩擦を下げられます。ただしSpannerは分散DBという性質上、主キー設計やインターリーブといったSpanner固有の考え方が性能を左右するため、既存スキーマをそのまま載せれば十分に動くわけではありません。単調増加する主キーを gen_random_uuid() に置き換えるなど、アクセスパターンから逆算した設計の見直しが移行の勘所になります。無料トライアルインスタンスで実データの一部を流し、クエリプランとホットスポットを確かめてから本番構成を決めるのが安全な順序です。
関連記事
- Cloud SpannerとBigQueryの連携方法｜外部データセット・連携クエリ・変更ストリームの使い分け：本記事の定義を踏まえた、分析連携とパフォーマンスの深掘り
- Cloud Bigtableとは？GCPのワイドカラム型NoSQLの仕組みと採用判断：単一キーの超高スループット向けNoSQL。SQL・結合が要らない用途との使い分け
- Amazon Auroraとは？仕組み・RDSとの違いと料金モデル：他クラウドのマネージドRDBとの比較で見るSpannerの立ち位置
- CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説：クラウドを跨いで動かせる分散SQL。Google Cloud固定でない案件での対抗馬
- データベースのスキーマとは？三層スキーマの違いと設計・管理の実務：インターリーブや主キー設計の前提になるスキーマ設計の基礎
