このページでは、Cloud Spanner で提供されるサービスの本番環境での割り当てと上限について説明します。割り当てと上限の違いは、上限は調整できないのに対して、割り当ては引き上げをリクエストできるという点にあります。
割り当ての値と上限の値は、変更される場合があります。
割り当てを確認する
プロジェクト用の現在のリソースの割り当て量を確認するには、Google Cloud Console を使用できます。
割り当てを増やす
時間とともに Cloud Spanner の使用量が多くなるに伴い、割り当てを増やすことができます。使用量の大幅な増加が見込まれる場合は、十分なサイズの割り当てを確保できるように、数日前にリクエストしてください。
Cloud Console の [割り当て] ページに移動します。
[サービス] プルダウン リストから [Cloud Spanner API] を選択します。
[Cloud Spanner API] が表示されない場合は、Cloud Spanner API が有効になっていません。
変更する割り当てを選択します。
[割り当てを編集] をクリックします。
名前、メールアドレス、電話番号を入力して、[次へ] をクリックします。
割り当てリクエストを入力して、[リクエストを送信] をクリックします。
リクエストの送信後、48 時間以内に Cloud Spanner チームから返答いたします。
インスタンスに関する制限
| 値 | 制限 |
|---|---|
| インスタンス ID の文字数 | 2～64 文字 |
データベースに関する制限
| 値 | 制限 |
|---|---|
| インスタンスあたりのデータベース数 | 100 |
| データベース ID の文字数 | 2～30 文字 |
| ノードあたりのストレージ サイズ | 2 TB1 バックアップは別に保存され、この上限にはカウントされません。詳細については、ストレージ使用率の指標をご覧ください。 |
バックアップと復元に関する上限
| 値 | 上限 |
|---|---|
| データベースあたりの継続的なバックアップ作成オペレーションの数 | 1 |
| インスタンス（バックアップのインスタンスではなく、復元されたデータベースのインスタンス）あたりの継続的なデータベース復元オペレーションの数 | 1 |
| バックアップの最大保持期間 | 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 キーを構成するすべての列のサイズを含む |
インデックス
| 値 | 上限 |
|---|---|
| データベースあたりのインデックス数 | 10,000 |
| テーブルあたりのインデックス数 | 32 |
| インデックス名の文字数 | 1～128 文字 |
| インデックス キーの列数 | 16 ベーステーブルのインデックスが作成された列（STORING 列を除く）の数と主キー列の数の合計 |
クエリに関する上限
| 値 | 上限 |
|---|---|
GROUP BY 句の列 |
1,000 |
| 関数の呼び出し | 1,000 |
| 結合 | 20 |
| ネストされた関数の呼び出し | 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 がセカンダリ インデックスに対して単一の範囲指定削除のオペレーションを呼び出すことが不可能になるためです。セカンダリ インデックスには外部キーのバックアップ インデックスが含まれます。
トランザクションのミューテーション数を確認するには、トランザクションの commit の統計情報を取得するをご覧ください。
3. 管理操作のリクエストに関する上限には、commit、注 5 に記載されたリクエスト、およびスキーマの変更は含まれません。
4. このレート制限には、インスタンス、データベース、バックアップで長時間実行オペレーションをポーリングする呼び出しをはじめとして、管理 API の呼び出しがすべて含まれます。
5. この上限が適用されるオペレーションには、データベースの作成、データベースの更新、読み取り、ストリーミング読み取り、SQL クエリの実行、ストリーミング SQL クエリの実行のリクエストなどがあります。