割り当てと上限

このページでは、Spanner で提供されるサービスの本番環境での割り当てと上限について説明します。割り当てと上限は、Google Cloud コンソールでは同じ意味で使用されます。

割り当ての値と上限の値は、変更される場合があります。

割り当ての確認と編集の権限

割り当て量を表示するには、serviceusage.quotas.get Identity and Access Management(IAM)権限を付与されている必要があります。

割り当てを変更するには、serviceusage.quotas.update IAM 権限が必要です。この権限は、事前定義ロールであるオーナー、編集者、割り当て管理者にデフォルトで含まれています。

これらの権限は、オーナーと編集者の基本の IAM ロール、および事前定義された割り当て管理者ロールにデフォルトで含まれています。

割り当てを確認する

プロジェクト用の現在のリソースの割り当て量を確認するには、Google Cloud コンソールを使用できます。

[割り当て] に移動

割り当てを増やす

時間とともに Spanner の使用量が多くなるに伴い、割り当てを増やすことができます。使用量の大幅な増加が見込まれる場合は、十分なサイズの割り当てを確保できるように、数日前にリクエストしてください。

コンシューマー割り当てオーバーライドを増やす必要がある場合もあります。詳細については、コンシューマー割り当てオーバーライドの作成をご覧ください。

Google Cloud コンソールを使用して、現在の Spanner インスタンス構成ノードの上限を増やすことができます。

  1. [割り当て] ページに移動します。

    [割り当て] ページに移動

  2. [サービス] プルダウン リストから [Spanner API] を選択します。

    Spanner API が表示されない場合は、Spanner API が有効になっていません。詳細については、API を有効にするをご覧ください。

  3. 変更する割り当てを選択します。

  4. [割り当てを編集] をクリックします。

  5. 表示される [割り当ての変更] パネルで、新しい割り当て上限を入力します。

    インスタンス作成ウィンドウのスクリーンショット

  6. [完了]、[リクエストを送信] の順にクリックします。

    必要なノード数を手動で目的の上限に引き上げることができない場合は、[割り当ての増加を申し込む] をクリックします。フォームに記入して、Spanner チームにリクエストを送信します。リクエスト後 48 時間以内に回答が届きます。

カスタム インスタンス構成の割り当てを増やす

カスタム インスタンス構成のノード割り当てを増やすことができます。

  1. ベース インスタンス構成のノード上限を確認して、カスタム インスタンス構成のノード上限を確認します。

    カスタム インスタンス構成の基本構成がわからない、または覚えていない場合には、show instance configuration details コマンドを使用します。

  2. カスタム インスタンス構成に必要なノード上限が 85 未満の場合は、前の割り当てを増やすの手順に従ってください。Google Cloud コンソールを使用して、カスタム インスタンス構成に関連付けられたベース インスタンス構成のノードの上限を増やします。

    カスタム インスタンスの構成に必要なノード上限が 85 を超える場合は、Spanner ノードの割り当ての引き上げリクエスト フォームに記入してください。カスタム インスタンス構成の ID をフォームで指定します。

ノードに関する上限

上限
インスタンス構成あたりのノード数

デフォルトの上限は、プロジェクトとインスタンスの構成によって異なります。プロジェクトの割り当て上限の変更や、上限の引き上げをリクエストするには、割り当ての引き上げをご覧ください。

インスタンスに関する上限

制限
インスタンス ID の文字数 2~64 文字

無料トライアル インスタンスの上限

Spanner の無料トライアル インスタンスには、次の追加の上限があります。これらの上限を増やす、または削除するには、無料トライアル インスタンスを有料インスタンスにアップグレードします。

上限
ストレージ容量 10 GB
データベースに関する上限 最大 5 つのデータベースを作成する
サポートされていない機能 バックアップと復元
SLA SLA 保証なし
試用期間 90 日間の無料試用期間

インスタンス構成の上限

上限
プロジェクトあたりのカスタム インスタンス構成の最大数 100
カスタム インスタンス構成 ID の長さ

8~164 文字

カスタム インスタンス構成 ID の先頭は custom- にする必要があります

データベースに関する制限

制限
インスタンスあたりのデータベース数
  • 1 ノード(1,000 処理ユニット)以上のインスタンスの場合: 100 データベース
  • ノードが 1 つ未満のインスタンスの場合: 100 処理単位あたり 10 データベース
データベースあたりのロール数 100
データベース ID の文字数 2~30 文字
ストレージ サイズ 1
  • 1 ノード(1,000 処理単位)以上のインスタンスの場合: ノードあたり 4 TB
  • ノード数が 1 未満のインスタンスの場合: 100 処理単位あたり 409.6 GB

特定のリージョンとマルチリージョンの Spanner インスタンス構成では、ノードあたり 10 TB のストレージ容量を増やすことができます。詳細については、パフォーマンスとストレージの改善をご覧ください。

バックアップは別に保存され、この上限にはカウントされません。詳細については、ストレージ使用率の指標をご覧ください。

Spanner では、使用可能なストレージの合計ではなく、インスタンス内で実際に使用されたストレージに対して課金されます。

バックアップと復元に関する上限

上限
データベースあたりの継続的なバックアップ作成オペレーションの数 1
インスタンス(バックアップのインスタンスではなく、復元されたデータベースのインスタンス)あたりの継続的なデータベース復元オペレーションの数 10
バックアップの最大保持期間 1 年(閏年の場合は追加される日を含む)

スキーマに関する上限

DDL ステートメント

上限
単一のスキーマ変更に関する DDL ステートメントのサイズ 10 MB
GetDatabaseDdl によって返される、データベースのスキーマ全体に関する DDL ステートメントのサイズ 10 MB

テーブル

上限
データベースあたりのテーブル数 5,000
テーブル名の文字数 1~128 文字
テーブルあたりの列数 1,024
列名の文字数 1~128 文字
セルあたりのデータのサイズ 10 MB
テーブルキーの列数

16

親テーブルと共有されているキー列を含む

テーブルのインターリーブ深度

7

子テーブルを持つトップレベル テーブルの深度は 1 です。

孫テーブルを持つトップレベル テーブルの深度は 2 となり、以降同様に深度が増えていきます。

テーブルまたはインデックス キーの合計サイズ

8 KB

キーを構成するすべての列のサイズを含む

非キー列の合計サイズ

1600 MB

テーブルのすべての非キー列のサイズを含む

インデックス

上限
データベースあたりのインデックス数 10,000
テーブルあたりのインデックス数 128
インデックス名の文字数 1~128 文字
インデックス キーの列数

16

ベーステーブルのインデックスが作成された列(STORING 列を除く)の数と主キー列の数の合計

ビュー

上限
データベースあたりのビュー数 5,000
ビューの長さ 1~128 文字
ネストの深さ

10

別のビューを参照するビューのネストの深さは 1 です。別のビューを参照するビューには、さらに別のビューを参照するビューがあり、ネストの深さは 2 と続きます。

クエリに関する上限

上限
GROUP BY 句の列 1,000
IN 演算子の値 10,000
関数の呼び出し 1,000
結合 20
ネストされた関数の呼び出し 75
ネストされた GROUP BY 35
ネストされたサブクエリ式 25
ネストされたサブセレクト文 60
パラメータ 950
クエリ文の文字数 100 万文字
STRUCT フィールド 1,000
サブクエリ式の子 50
クエリ内のユニオン 200

データの作成、読み取り、更新、削除に関する上限

上限
commit サイズ(インデックスと変更ストリームを含む) 100 MB
セッションあたりの同時読み取り数 100
commit あたりのミューテーション(インデックスを含む)2 80,000
データベースあたりのパーティション化 DML の同時実行ステートメント数 20,000

管理操作に関する上限

上限
管理操作のリクエスト サイズ3 1 MB
管理操作のレート制限4

ユーザーごとのプロジェクトあたりで 1 秒ごとに 5

(100 秒間の平均)

リクエストに関する上限

上限
commit 以外のリクエスト サイズ5 10 MB

ストリーム制限を変更する

上限
データベースあたりの変更ストリーム 10
指定した非キー列を視聴するストリームの変更6 3
変更ストリーム データ パーティションあたりの同時読み取り数7 5

データブーストの上限

上限
同時データブースト リクエスト8 200

メモ

1. Spanner でデータベースへのアクセスの可用性を高め、レイテンシを低く抑えるには、インスタンスのコンピューティング容量に基づいてストレージの上限を定義します。

  • 1 ノード(1,000 処理単位)未満のインスタンスの場合、Spanner ではデータベース内の 100 処理単位ごとに 409.6 GB のデータが割り当てられます。
  • 1 ノード以上のインスタンスの場合、Spanner はノードあたり 4 TB のデータを割り当てます。

たとえば、600 GB のデータベースのインスタンスを作成するには、そのコンピューティング容量を 200 処理単位に設定する必要があります。コンピューティング容量がこの容量に達すると、データベースが 819.2 GB を超えるまで、インスタンスは上限を下回るままになります。データベースがこのサイズを超過する場合、さらに 100 のプロセッシング ユニットを追加して、データベースの増大に対応する必要があります。増大しないと、データベースへの書き込みが拒否される可能性があります。詳細については、データベース ストレージ使用率の推奨事項をご覧ください。

データベースをスムーズに拡張していくには、このサイズ上限に達する前にコンピューティング容量を追加するようにしてください。

2. 挿入と更新のオペレーション回数は、オペレーションの影響を受ける列数を単位としてカウントされ、主キー列は常に影響を受けます。たとえば、5 つの列に値を挿入すると、新しいレコードの挿入は 5 つのミューテーションとしてカウントされます。レコードに 2 つの主キー列がある場合、レコード内の 3 つの列を更新した場合も 5 つのミューテーションとしてカウントされます。また、削除と範囲指定削除のオペレーションは、影響を受ける列の数に関係なく 1 つのミューテーションとしてカウントされます。ON DELETE CASCADE アノテーションを含む親テーブルからの行の削除も、存在するインターリーブされた子行の数に関係なく 1 つのミューテーションとしてカウントされます。削除される行にセカンダリ インデックスが定義されている場合は例外であり、このセカンダリ インデックスへの変更は個別にカウントされます。たとえば、テーブルに 2 つのセカンダリ インデックスがある場合、テーブル内の特定の範囲の行を削除すると、テーブルに対して 1 つのミューテーションとしてカウントされ、加えて、削除される各行に対して 2 つのミューテーションとしてカウントされます。これは、セカンダリ インデックス内の行がキー空間内に散らばっていることにより、Spanner がセカンダリ インデックスに対して単一の範囲指定削除のオペレーションを呼び出すことが不可能になるためです。セカンダリ インデックスには外部キーのバックアップ インデックスが含まれます。

トランザクションのミューテーション数を確認するには、トランザクションの commit の統計情報を取得するをご覧ください。

変更ストリームには、この上限にカウントされるミューテーションは追加されません。

3. 管理操作のリクエストに関する上限には、commit、注 5 に記載されたリクエスト、およびスキーマの変更は含まれません。

4. このレート制限には、インスタンス、データベース、バックアップで長時間実行オペレーションをポーリングする呼び出しをはじめとして、管理 API の呼び出しがすべて含まれます。

5. この上限が適用されるオペレーションには、データベースの作成、データベースの更新、読み取り、ストリーミング読み取り、SQL クエリの実行、ストリーミング SQL クエリの実行のリクエストなどがあります。

6. テーブルまたはデータベース全体を監視する変更ストリームは、そのテーブルまたはデータベースのすべての列を暗黙的に監視するため、この上限にカウントされます。

7. この上限は、Dataflow パイプラインか直接 API クエリによる読取りかにかかわらず、同じ変更ストリーム パーティションの同時読取りに適用されます。

8. デフォルトの上限はプロジェクトとリージョンによって異なります。詳細については、Data Boost 割り当て使用量のモニタリングと管理をご覧ください。