割り当てと上限

このページでは、Cloud Spanner で提供されるサービスの本番環境での割り当てと上限について説明します。割り当てと上限の違いは、上限は調整できないのに対して、割り当ては引き上げをリクエストできるという点にあります。

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

割り当てを確認する

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

割り当てを確認する

割り当てを増やす

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

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

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

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

    [Cloud Spanner API] が表示されない場合は、Cloud Spanner API が有効になっていません。

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

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

  5. 名前、メールアドレス、電話番号を入力して、[次へ] をクリックします。

  6. 割り当てリクエストを入力して、[リクエストを送信] をクリックします。

リクエストの送信後、48 時間以内に Cloud Spanner チームから返答いたします。

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

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

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

制限
インスタンスあたりのデータベース数 100
データベース ID の文字数 2~30 文字
ノードあたりのストレージ サイズ 2 TB1

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

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

スキーマに関する上限

DDL ステートメント

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

テーブル

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

16

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

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

7

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

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

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

8 KB

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

行あたりのデータのサイズ

4 GB

最上位の行と、そのインターリーブされた子とインデックス行をすべて含む

インデックス

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

16

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

クエリに関する上限

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

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

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

管理操作に関する上限

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

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

(100 秒間の平均)

リクエストに関する上限

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

1. Cloud Spanner でデータベースへのアクセスの可用性を高め、レイテンシを低く抑えるには、データベース内のデータ 2 TB あたり 1 台のノードが必要となります。たとえば、3.5 TB のデータを格納する 1 つのデータベースがインスタンスにある場合は、2 つ以上のノードをプロビジョニングする必要があります。このようなノードでは、データベースのサイズが 4 TB になるまではインスタンスを上限以下に維持できます。データベースがこのサイズを超過する場合、別のノードを追加してデータベースの増大に対応する必要があります。対応しないと、データベースへの書き込みでエラーが発生します。データベースをスムーズに拡張していくには、このサイズ上限に達する前にノードを追加するようにしてください。

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

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

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

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