このページでは、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 キーを構成するすべての列のサイズを含む |
行あたりのデータのサイズ | 4 GB 最上位の行と、そのインターリーブされた子とインデックス行をすべて含む |
インデックス
値 | 上限 |
---|---|
データベースあたりのインデックス数 | 10,000 |
テーブルあたりのインデックス数 | 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 クエリの実行のリクエストなどがあります。