このページでは、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 GiB |
| データベースに関する上限 | 最大 5 つのデータベースを作成 |
| サポートされていない機能 | バックアップと復元 |
| SLA | SLA なし |
| 試用期間 | 90 日間の無料試用期間 |
地域別パーティション分割の上限
| 値 | 上限 |
|---|---|
| インスタンスあたりのパーティションの最大数 | 10 |
| パーティション内のノードあたりのプレースメント行の最大数 | 1 億 |
保存済みクエリの上限
| 値 | 上限 |
|---|---|
| プロジェクトごとの保存済みクエリの最大数（他の Google Cloud プロダクトの保存済みクエリを含む） | 10,000 |
| 各クエリの最大サイズ | 1 MiB |
インスタンス構成の上限
| 値 | 上限 |
|---|---|
| プロジェクトあたりのカスタム インスタンス構成の最大数 | 100 |
| カスタム インスタンス構成 ID の長さ | 8～64 文字 カスタム インスタンス構成 ID の先頭は |
データベースに関する制限
| 値 | 上限 |
|---|---|
| インスタンスあたりのデータベース数 |
|
| データベースあたりのロール | 100 |
| データベース ID の文字数 | 2～30 文字 |
| ストレージ サイズ1 |
ほとんどのリージョン、デュアルリージョン、マルチリージョンの Spanner インスタンス構成で、ノードあたり 10 TiB のストレージ容量を増強できます。詳細については、パフォーマンスとストレージの改善をご覧ください。 階層ストレージを使用する場合は、ノードあたり最大 10 TiB のストレージ（SSD と HDD）を組み合わせて使用できます。 バックアップは別に保存され、この上限にはカウントされません。詳細については、ストレージ使用率の指標をご覧ください。 Spanner では、使用可能なストレージの合計ではなく、インスタンス内で実際に使用されたストレージに対して課金されます。 |
バックアップと復元に関する上限
| 値 | 上限 |
|---|---|
| データベースあたりの継続的なバックアップ作成オペレーションの数 | 1 |
| インスタンス（バックアップのインスタンスではなく、復元されたデータベースのインスタンス）あたりの継続的なデータベース復元オペレーションの数 | 10 |
| バックアップの最大保持期間 | 1 年（閏年の場合は追加される日を含む） |
スキーマに関する上限
スキーマ オブジェクト
| 値 | 上限 |
|---|---|
| 同じインスタンス内のすべてのデータベース内にあるスキーマ オブジェクトの合計数 | デフォルトの上限は、インスタンスの構成によって異なります9 |
DDL ステートメント
| 値 | 上限 |
|---|---|
| 単一のスキーマ変更に関する DDL ステートメントのサイズ | 10 MiB |
GetDatabaseDdl によって返される、データベースのスキーマ全体に関する DDL ステートメントのサイズ |
10 MiB |
グラフ
| 値 | 上限 |
|---|---|
| データベースあたりのプロパティ グラフ | 16 |
| プロパティ グラフ名の長さ | 1～128 文字 |
テーブル
| 値 | 上限 |
|---|---|
| データベースあたりのテーブル数 | 5,000 |
| テーブル名の文字数 | 1～128 文字 |
| テーブルあたりの列数 | 1,024 |
| 列名の文字数 | 1～128 文字 |
| セルごとのデータのサイズ | 10 MiB |
STRING セルのサイズ |
2,621,440 Unicode 文字 |
| テーブルキーの列数 | 16 親テーブルと共有されているキー列を含む |
| テーブルのインターリーブ深度 | 7 子テーブルを持つトップレベル テーブルの深度は 1 です。 孫テーブルを持つトップレベル テーブルの深度は 2 となり、以降同様に深度が増えていきます。 |
| テーブルまたはインデックス キーの合計サイズ | 8 KB キーを構成するすべての列のサイズを含む |
| 非キー列の合計サイズ | 1600 MiB テーブルのすべての非キー列のサイズを含む |
インデックス
| 値 | 上限 |
|---|---|
| データベースあたりのインデックス数 | 10,000 |
| テーブルあたりのインデックス数 | 128 |
| インデックス名の文字数 | 1～128 文字 |
| インデックス キーの列数 | 16 ベーステーブルのインデックスが作成された列（STORING 列を除く）の数と主キー列の数の合計 |
ビュー
| 値 | 上限 |
|---|---|
| データベースあたりのビュー | 5,000 |
| ビューの名前の長さ | 1～128 文字 |
| ネストの深さ | 10 別のビューを参照するビューのネストの深さは 1 です。別のビューを参照し、そのビューがさらに別のビューを参照する場合、ネストの深度 2 というようになります。 |
地域グループ
| 値 | 上限 |
|---|---|
| データベースあたりの地域グループの最大数 | 16（デフォルトの地域グループ 1 つと、オプションの追加地域グループ 15 個） |
ssd_to_hdd_spill_timespan オプションで必要な最小時間 |
1 時間 |
ssd_to_hdd_spill_timespan オプションで許可される最大時間 |
365 日 |
クエリに関する上限
| 値 | 上限 |
|---|---|
GROUP BY 句の列 |
1,000 |
IN 演算子の値 |
10,000 |
| 関数の呼び出し | 1,000 |
| 結合 | 20 |
| ネストされた関数の呼び出し | 75 |
ネストされた GROUP BY 句 |
35 |
| ネストされたサブクエリ式 | 25 |
| ネストされたサブセレクト文 | 60 |
| グラフクエリによって生成された結合 | 100 |
| パラメータ | 950 |
| クエリ文の文字数 | 100 万文字 |
STRUCT フィールド |
1,000 |
| サブクエリ式の子 | 50 |
| クエリ内のユニオン | 200 |
| グラフの定量化されたパス走査の深さ | 100 |
データの作成、読み取り、更新、削除に関する上限
| 値 | 上限 |
|---|---|
| commit サイズ（インデックスと変更ストリームを含む） | 100 MiB |
| セッションあたりの同時読み取り数 | 100 |
| commit あたりのミューテーション（インデックスを含む）2 | 80,000 |
| データベースあたりのパーティション化 DML の同時実行ステートメント数 | 20,000 |
管理操作に関する上限
| 値 | 上限 |
|---|---|
| 管理操作のリクエスト サイズ3 | 1 MiB |
| 管理操作のレート制限4 | ユーザーごとのプロジェクトあたりで 1 秒ごとに 5 （100 秒間の平均） |
リクエストに関する上限
| 値 | 上限 |
|---|---|
| commit 以外のリクエスト サイズ5 | 10 MiB |
変更ストリームの上限
| 値 | 上限 |
|---|---|
| データベースあたりの変更ストリーム数 | 10 |
| 指定した非キー列を監視する変更ストリーム6 | 3 |
| 変更ストリーム データ パーティションあたりの同時実行読み取り7 | 5 |
Data Boost の上限
| 値 | 上限 |
|---|---|
| us-central1 のプロジェクトあたりの同時実行 Data Boost リクエスト数 | 1000 8 |
| 他のリージョンのリージョンごと、プロジェクトごとの同時実行 Data Boost リクエスト数 | 400 8 |
事前分割 API の上限
| 値 | 上限 |
|---|---|
| API リクエストごとに追加される分割点 | 100 |
| 分割点 API リクエスト サイズ | 1 MiB |
| インスタンス内のすべてのデータベースに対してノードごとに追加された分割点 | 50 |
| ノードあたり 1 分あたりの分割点の追加または更新 | 10 |
| ノードあたり 1 日あたりの分割点の追加または更新 | 200 |
メモ
1. Spanner でデータベースへのアクセスの可用性を高め、レイテンシを低く抑えるには、インスタンスのコンピューティング容量に基づいてストレージの上限を定義します。
- 1 ノード（1,000 処理単位）未満のインスタンスの場合、Spanner はデータベース内の 100 処理単位ごとに 1,024.0 GiB のデータを割り当てます。
- 1 ノード以上のインスタンスの場合、Spanner はノードごとに 10 GiB のデータを割り当てます。
たとえば、1500 GiB のデータベース用のインスタンスを作成する場合、そのコンピューティング容量を 200 処理単位に設定する必要があります。コンピューティング容量がこの容量に達すると、データベースが 2,048.0 GiB を超えるまで、インスタンスは上限を下回るままになります。データベースがこのサイズを超えた場合は、データベースを拡大できるように、さらに 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. 報告されるスキーマ オブジェクトには、テーブル、列、インデックス、シーケンスなど、DDL で説明されているすべてのオブジェクト タイプが含まれます。スキーマ オブジェクトの上限はインスタンス レベルで適用され、インスタンスで使用可能な処理単位によって異なります。
- 1 ノード以上のインスタンスの場合、デフォルトの上限は 100 万オブジェクトです。
- 1 ノード（1,000 処理ユニット）未満のインスタンスの場合、上限はインスタンスのサイズに比例して減少します。たとえば、100 個の処理ユニットを持つインスタンスの場合、上限は 10 万個のスキーマ オブジェクトです。
データベースのスキーマ オブジェクト数とインスタンスのオブジェクトの上限を確認するには、Metrics Explorer で指標 spanner.googleapis.com/instance/schema_objects と spanner.googleapis.com/instance/schema_object_count を探します。モニタリングの詳細については、Cloud Monitoring でインスタンスをモニタリングするをご覧ください。
上限に達すると、Spanner は、次のような上限を超えるオペレーションを実行できなくなります。
- データベースのスキーマの修正（たとえば、インデックスの追加）
- インスタンスに新しいデータベースを作成します。
- バックアップから同じインスタンスにデータベースを復元する。この場合、同じ構成の別のインスタンスにバックアップを復元することも、同じ構成で新しいインスタンスを作成して、新しいインスタンスにバックアップを復元することもできます。