このページでは、Spanner で提供されるサービスの本番環境での割り当てと上限について説明します。割り当てと上限は、Google Cloud コンソールでは同じ意味で使用されます。
割り当ての値と上限の値は、変更される場合があります。
割り当てを確認、編集する権限
割り当てを表示するには、serviceusage.quotas.get Identity and Access Management（IAM）権限が必要です。
割り当てを変更するには、serviceusage.quotas.update
IAM 権限が必要です。この権限は、事前定義ロールであるオーナー、編集者、割り当て管理者にデフォルトで含まれています。
これらの権限は、オーナーと編集者の基本の IAM ロール、および事前定義された割り当て管理者ロールにデフォルトで含まれています。
割り当てを確認する
プロジェクト用の現在のリソースの割り当て量を確認するには、Google Cloud コンソールを使用できます。
割り当てを増やす
時間とともに Spanner の使用量が多くなるに伴い、割り当てを増やすことができます。使用量の大幅な増加が見込まれる場合は、十分なサイズの割り当てを確保できるように、数日前にリクエストしてください。
場合によっては、コンシューマーの割り当てオーバーライドを増やす必要があります。詳細については、コンシューマー割り当てオーバーライドの作成をご覧ください。
Google Cloud コンソールを使用して、現在の Spanner インスタンス構成ノードの上限を増やすことができます。
[割り当て] ページに移動します。
[サービス] プルダウン リストから [Spanner API] を選択します。
[Spanner API] が表示されない場合は、Spanner API が有効になっていません。詳細については、API を有効にするをご覧ください。
変更する割り当てを選択します。
[割り当てを編集] をクリックします。
表示される [割り当ての変更] パネルで、新しい割り当て上限を入力します。
[完了]、[リクエストを送信] の順にクリックします。
必要なノード数を手動で目的の上限に引き上げることができない場合は、[割り当ての増加を申し込む] をクリックします。フォームに記入して、Spanner チームにリクエストを送信します。リクエスト後 48 時間以内に回答が届きます。
カスタム インスタンス構成の割り当てを増やす
カスタム インスタンス構成のノード割り当てを増やすことができます。
ベース インスタンス構成のノード上限を確認して、カスタム インスタンス構成のノード上限を確認します。
カスタム インスタンス構成の基本構成がわからない、または覚えていない場合には、show instance configuration details コマンドを使用します。
カスタム インスタンス構成に必要なノード上限が 85 未満の場合は、前の割り当てを増やすの手順に従ってください。Google Cloud コンソールを使用して、カスタム インスタンス構成に関連付けられたベース インスタンス構成のノードの上限を増やします。
カスタム インスタンスの構成に必要なノード上限が 85 を超える場合は、Spanner ノードの割り当ての引き上げリクエスト フォームに記入してください。カスタム インスタンス構成の ID をフォームで指定します。
ノードに関する上限
| 値 | 上限 |
|---|---|
| インスタンス構成あたりのノード数 |
デフォルトの上限は、プロジェクトとインスタンスの構成によって異なります。プロジェクトの割り当て上限の変更や、上限の引き上げをリクエストするには、割り当ての引き上げをご覧ください。 |
インスタンスに関する上限
| 値 | 上限 |
|---|---|
| インスタンス ID の文字数 | 2～64 文字 |
無料トライアル インスタンスの上限
Spanner の無料トライアル インスタンスには、以下の追加制限があります。これらの上限を引き上げるか削除するには、無料トライアル インスタンスを有料インスタンスにアップグレードします。
| 値 | 上限 |
|---|---|
| ストレージ容量 | 10 GB |
| データベースの上限 | 最大 5 つのデータベースを作成する |
| サポートされていない機能 | バックアップと復元 |
| SLA | SLA の保証なし |
| 試用期間 | 90 日間の無料試用期間 |
インスタンス構成の上限
| 値 | 上限 |
|---|---|
| プロジェクトあたりのカスタム インスタンス構成の最大数 | 100 |
| カスタム インスタンス構成 ID の長さ | 8～164 文字 カスタム インスタンス構成 ID の先頭は |
地域別パーティション分割の制限
| 値 | 上限 |
|---|---|
| インスタンスあたりのパーティションの最大数 | 10 |
| パーティション内のノードあたりのプレースメント行の最大数9 | 2,000 万 |
データベースに関する制限
- 1 ノード（1,000 処理単位）以上のインスタンスの場合: ノードあたり 4 TB
- ノード数が 1 未満のインスタンスの場合: 100 処理単位あたり 409.6 GB
ノードあたり 10 TB のストレージ容量の増加は、ほとんどのリージョン、デュアルリージョン、マルチリージョンの Spanner インスタンス構成で利用できます。詳細については、パフォーマンスとストレージの改善をご覧ください。
バックアップは別に保存され、この上限にはカウントされません。詳細については、ストレージ使用率の指標をご覧ください。
Spanner では、使用可能なストレージの合計ではなく、インスタンス内で実際に使用されたストレージに対して課金されます。
| 値 | 上限 |
|---|---|
| インスタンスあたりのデータベース数 |
|
| データベースあたりのロール | 100 |
| データベース ID の文字数 | 2～30 文字 |
| ストレージ サイズ 1 |
バックアップと復元に関する上限
| 値 | 上限 |
|---|---|
| データベースあたりの継続的なバックアップ作成オペレーションの数 | 1 |
| インスタンス（バックアップのインスタンスではなく、復元されたデータベースのインスタンス）あたりの継続的なデータベース復元オペレーションの数 | 10 |
| バックアップの最大保持期間 | 1 年（閏年の場合は追加される日を含む） |
スキーマに関する上限
DDL ステートメント
| 値 | 上限 |
|---|---|
| 単一のスキーマ変更に関する DDL ステートメントのサイズ | 10 MB |
GetDatabaseDdl によって返される、データベースのスキーマ全体に関する DDL ステートメントのサイズ |
10 MB |
テーブル
| 値 | 上限 |
|---|---|
| データベースあたりのテーブル数 | 5,000 |
| テーブル名の文字数 | 1～128 文字 |
| テーブルあたりの列数 | 1,024 |
| 列名の文字数 | 1～128 文字 |
| セルあたりのデータのサイズ | 10 MiB |
STRING セルのサイズ |
Unicode 形式の 2,621,440 個の文字 |
| テーブルキーの列数 | 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 |
Data Boost の上限
| 値 | 上限 |
|---|---|
| us-central1 のプロジェクトあたりの同時実行 Data Boost リクエスト数 | 1000 8 |
| 他のリージョンのリージョンごと、プロジェクトごとの同時実行 Data Boost リクエスト数 | 400 8 |
メモ
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 割り当て使用量のモニタリングと管理をご覧ください。
9. 地域別パーティション分割では、ほとんどのパーティションにノードあたり 2,000 万個のプレースメント行の上限があります。us-west4、nam10、nam-eur-asia1 の構成を使用するパーティションには、ノードあたり 1,000 万個のプレースメント行の上限があります。