Azure AI Search のサービス制限
ストレージ、ワークロード、インデックスおよびその他のオブジェクトの量の最大制限は、Azure AI Search を Free 、Basic 、Standard 、またはストレージ最適化価格レベル でプロビジョニングするどうかによって異なります。
Free は、Azure サブスクリプションに付属しているマルチテナント共有サービスです。
Basic では、小規模な運用ワークロードに対して専用のコンピューティング リソースが提供されますが、一部のネットワーク インフラストラクチャは他のテナントと共有されます。
Standard は、すべてのレベルでさらに多くのストレージや処理能力を持つ専用マシン上で実行されます。 Standard には 4 つのレベル (S1、S2、S3、S3 HD) があります。 S3 高密度 (S3 HD) は、マルチテナントと大量の小さなインデックス (サービスあたり 3,000 インデックス) 向けに設計されています。 S3 HD では、インデクサー機能は提供されません。また、データ インジェストでは、ソースからインデックスにデータをプッシュする API を使用する必要があります。
ストレージ最適化は、Standard よりも多くの合計ストレージ、ストレージ帯域幅、およびメモリを備えた専用マシンで実行されます。 このレベルでは、大型で、緩やかに変化するインデックスが対象となります。 ストレージ最適化には、L1 と L2 の 2 つのレベルがあります。
サブスクリプションの制限
複数の "課金対象"の検索サービス (Basic 以上) を作成できます。これは、各レベルで許可されるサービスの数によってのみ制限されます。 たとえば、Basic レベルのサービスであれば 16 個まで作成できますが、同じサブスクリプションの枠内で S1 レベルのサービスをさらにもう 16 個まで作成できます。 レベルの詳細については、「Azure AI Searchの SKU またはレベルを選択する」を参照してください。
サービス数の上限は、依頼により引き上げが可能です。 同一のサブスクリプション内にさらに多くのサービスが必要な場合は、サポート リクエストを提出してください。
| リソース | Free1 | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 最大サービス数 | 1 | 16 | 16 | 8 | 6 | 6 | 6 | 6 |
| 検索単位の最大スケール (SU)2 | 該当なし | 3 SU | 36 SU | 36 SU | 36 SU | 36 SU | 36 SU | 36 SU |
1 Azure サブスクリプションごとに 1 つの無料検索サービスを使用できます。 Free レベルでは、他の顧客と共有されているインフラストラクチャに基づいて作成されます。 ハードウェアは専用ではないため、スケールアップはサポートされておらず、ストレージは 50 MB に制限されています。
2 Search ユニットは、レプリカまたはパーティションのいずれかとして割り当てられている請求単位です。 ストレージ、インデックス作成、およびクエリ操作については、両方のリソースが必要になります。 SU の計算の詳細については、クエリとインデックス作成のワークロードに応じたリソース レベルのスケーリングに関するページを参照してください。
ストレージの制限
検索サービスは、ディスク領域と、インデックスまたはインデクサーの最大数のハード制限のうち、先に達したものによって制約されます。 次の表では、ストレージの制限についてまとめています。 オブジェクトの上限については、リソース別の制限に関するセクションを参照してください。
| リソース | Free | Basic1 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| サービス レベル アグリーメント (SLA)2 | いいえ | イエス | イエス | イエス | イエス | イエス | イエス | はい |
| パーティションあたりのストレージ容量 | 50 MB | 2 GB | 25 GB | 100 GB | 200 GB | 200 GB | 1 TB (テラバイト) | 2 TB |
| サービスあたりのパーティション数 | 該当なし | 1 | 12 | 12 | 12 | 3 | 12 | 12 |
| パーティション サイズ | 該当なし | 2 GB | 25 GB | 100 GB | 200 GB | 200 GB | 1 TB (テラバイト) | 2 TB |
| レプリカ | 該当なし | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
1 Basic には、1 つの固定パーティションがあります。 追加の検索ユニットを使用することで、レプリカを追加してより多くのクエリを実行できます。
2 専用リソースの課金対象のサービスでは、サービス レベル アグリーメントが有効です。 Free サービスおよびプレビュー機能には SLA がありません。 課金対象のサービスで、SLA が有効になるのは、サービスに対して十分な冗長性がプロビジョニングされている場合です。 クエリ (読み取り) の SLA には複数のレプリカが必要です。 クエリとインデックス作成 (読み取り/書き込み) の SLA には 3 つ以上のレプリカが必要です。 パーティション数は SLA には関係ありません。
インデックスの制限
| リソース | 制限なし | 基本 1 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 最大インデックス | 3 | 5 または 15 | 50 | 200 | 200 | パーティションあたり 1,000、またはサービスあたり 3,000 | 10 | 10 |
| インデックスあたりの単純型フィールドの最大数 2 | 1000 | 100 | 1000 | 1000 | 1000 | 1000 | 1000 | 1000 |
| インデックスあたりの複合コレクション フィールドの最大数 | 40 | 40 | 40 | 40 | 40 | 40 | 40 | 40 |
| ドキュメントあたりの複合コレクション全体での最大要素数 3 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 |
| 複合フィールドの最大深度 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| インデックスあたりの最大サジェスター | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| インデックスあたりの最大スコアリング プロファイル | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
| プロファイルあたりの最大関数 | 8 | 8 | 8 | 8 | 8 | 8 | 8 | 8 |
1 2017 年 12 月より前に作成された Basic サービスは、インデックスでの制限が低くなっています (15 ではなく 5)。 Basic レベルにのみ下限 (インデックスあたり 100 フィールド) があります。
2 フィールドの上限には、複合コレクション内の第 1 レベルのフィールドと入れ子になったサブフィールドの両方が含まれます。 たとえば、インデックスに 15 個のフィールドが含まれており、それぞれ 5 つのサブフィールドを持つ 2 つの複合コレクションがある場合、インデックスのフィールド数は 25 になります。 フィールド コレクションが非常に大きい場合、インデックスの処理速度が低下する場合があります。 フィールドと属性を必要なものだけに制限し、インデックス作成とクエリ テストを実行して、パフォーマンスが許容できることを確認します。
3 多数の要素があると、インデックスに必要なストレージは大幅に増えるため、要素には上限があります。 複合コレクションの要素は、そのコレクションのメンバーとして定義されます。 たとえば、部屋の複合コレクションが記載されているホテル ドキュメントがあるとします。部屋コレクション内の各部屋は、1 つの要素として見なされます。 インデックス作成時は、インデックス作成エンジンによって、ドキュメント全体で最大 3,000 の要素が安全に処理されます。 この制限は api-version=2019-05-06 で導入され、文字列コレクションや複合フィールドではなく、複合コレクションにのみ適用されます。
サービスがより強力なクラスターでプロビジョニングされている場合は、上限に多少の違いがあることがあります。 ここでの制限は、共通の分母を表します。 上記の仕様に基づいて構築されたインデックスは、任意のリージョンの同等のサービス レベル間で移植できます。
ドキュメントの制限
Azure AI Search のサービスごとのドキュメント制限はなくなりましたが、Basic、S1、S2、S3、L1、L2 の検索サービスでは、インデックスあたり約 240 億ドキュメントの制限があります。 S3 HD の場合、制限は、インデックスあたり 20 億ドキュメントです。 制限に関しては、複合コレクションの各要素は個別のドキュメントとしてカウントされます。
API 呼び出しごとのドキュメント サイズの制限
インデックス API を呼び出すときのドキュメント サイズの上限は約 16 メガバイトです。
ドキュメント サイズとは、実際にはインデックス API の要求本文のサイズに対する制限を意味します。 複数のドキュメントのバッチを一度にインデックス API に渡すことができるため、このサイズの制限は、現実的には、バッチ内のドキュメント数に左右されます。 バッチ内のドキュメントが 1 つの場合、最大ドキュメント サイズは JSON 形式で 16 MB です。
ドキュメント サイズを推定する場合は、検索サービスで使用できるフィールドのみを考慮してください。 ソース ドキュメント内のバイナリ データまたはイメージ データはすべて、計算から除外する必要があります。
ベクトル インデックス サイズの制限
ベクター フィールドを使用してドキュメントにインデックスを作成すると、Azure AI Search は、指定したアルゴリズム パラメーターを使用して内部ベクター インデックスを構築します。 これらのベクトル インデックスのサイズは、サービスのレベル (または SKU) のベクトル検索用に予約されたメモリによって制限されます。
このサービスでは、検索サービス内のすべてのパーティションに対して、ベクトル インデックス サイズのクォータ が適用されます。 追加パーティションごとに、使用可能なベクトル インデックス サイズのクォータが増加します。 このクォータは、サービスが正常な状態を保つためのハード制限です。つまり、制限を超えてインデックスを作成しようとすると、エラーが発生します。 一部のベクトル ドキュメントを削除するか、パーティションでスケールアップを行うことで、使用可能なクォータを解放すれば、インデックス作成を再開できます。
この表は、サービス レベル (または SKU) 全体のパーティションあたりのベクトル インデックス サイズのクォータについて説明しています。 コンテキストの場合、次のものが含まれます。
- 各層の ストレージ制限。コンテキストについてはここで繰り返します。
- ベクター インデックスで使用できる各パーティションの量 (GB 単位) (インデックスにベクター フィールドを追加するときに作成されます)。
- パーティションあたりの埋め込み (浮動小数点値) の概算数。
サービス統計情報の取得 API (GET /servicestats) を使用して、ベクトル インデックス サイズのクォータを取得します。 詳細については、ベクトル インデックス サイズに関するドキュメントを参照してください。
2023 年 7 月 1 日より前に作成されたサービス
| レベル | ストレージ クォータ (GB) | パーティションあたりのベクトル クォータ (GB) | パーティションあたりの概算 float (15% のオーバーヘッドを想定) |
|---|---|---|---|
| Basic | 2 | 0.5 | 1 億 1,500 万 |
| S1 | 25 | 1 | 2 億 3,500 万 |
| S2 | 100 | 6 | 14 億 |
| S3 | 200 | 12 | 28 億 |
| L1 | 1,000 | 12 | 28 億 |
| L2 | 2,000 | 36 | 84 億 |
サポートされているリージョンで 2023 年 7 月 1 日以降に作成されたサービス
Azure AI Search では、新しい検索サービス のベクター インデックス サイズの制限が世界中でロールアウトされていますが、チームは特定のリージョンでインフラストラクチャ容量を構築しています。 残念ながら、既存のサービスを新しい制限に移行することはできません。
次のリージョンでは、制限の引き上げはサポートされていません。
- ドイツ中西部
- JIO インド西部
- カタール中部
| レベル | ストレージ クォータ (GB) | パーティションあたりのベクトル クォータ (GB) | パーティションあたりの概算 float (15% のオーバーヘッドを想定) |
|---|---|---|---|
| Basic | 2 | 1 | 2 億 3,500 万 |
| S1 | 25 | 3 | 7 億 |
| S2 | 100 | 12 | 28 億 |
| S3 | 200 | 36 | 84 億 |
| L1 | 1,000 | 12 | 28 億 |
| L2 | 2,000 | 36 | 84 億 |
インデクサー制限
サービスに全体としてのバランスと安定性を提供するために、最大実行時間が設けられていますが、より大規模なデータ セットでは、許可されている最大値よりも長いインデックス作成時間が必要になることがあります。 インデックス作成ジョブを最大許容時間内を完了できない場合は、スケジュールで実行してみてください。 スケジューラはインデックスの状態を追跡します。 スケジュールされたインデックス作成ジョブが何らかの理由で中断された場合、インデクサーは、次のスケジュールされた実行時に最後の終了状態を選択できます。
| リソース | 空き 1 | 基本 2 | S1 | S2 | S3 | S3 HD 3 | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 最大インデクサー | 3 | 5 または 15 | 50 | 200 | 200 | 該当なし | 10 | 10 |
| 最大データソース | 3 | 5 または 15 | 50 | 200 | 200 | 該当なし | 10 | 10 |
| 最大スキルセット 4 | 3 | 5 または 15 | 50 | 200 | 200 | 該当なし | 10 | 10 |
| 呼び出しあたりの最大インデックス作成負荷 | 10,000 ドキュメント | 最大ドキュメントによってのみ制限 | 最大ドキュメントによってのみ制限 | 最大ドキュメントによってのみ制限 | 最大ドキュメントによってのみ制限 | 該当なし | 制限なし | 制限なし |
| 最小限のスケジュール | 5 分 | 5 分 | 5 分 | 5 分 | 5 分 | 5 分 | 5 分 | 5 分 |
| 最大実行時間 6 | 1 ～ 3 分 | 2 または 24 時間 | 2 または 24 時間 | 2 または 24 時間 | 2 または 24 時間 | 該当なし | 2 または 24 時間 | 2 または 24 時間 |
| スキルセット 5 のインデクサー最大実行時間 | 3 から 10 分 | 2 時間 | 2 時間 | 2 時間 | 2 時間 | 該当なし | 2 時間 | 2 時間 |
| BLOB インデクサー: BLOB の最大サイズ、MB | 16 | 16 | 128 | 256 | 256 | 該当なし | 256 | 256 |
| BLOB インデクサー: BLOB から抽出されたコンテンツの最大文字数 | 32,000 | 64,000 | 400 万 | 800 万 | 1600 万 | 該当なし | 400 万 | 400 万 |
1 Free サービスのインデクサーの最大実行時間は、BLOB ソースの場合は 3 分、その他のすべてのデータ ソースの場合は 1 分です。 インデクサー呼び出しは 180 秒に 1 回です。 Azure AI サービス に呼び出しを行う AI インデックスについては、トランザクションが強化パイプラインを正常に通過するドキュメントとして定義された場合、無料のサービスは 1 日あたりインデクサーごとに 20 件の無料トランザクションに制限されます (ヒント：インデクサーをリセットしてカウントをリセットできます)。
2 2017 年 12 月より前に作成された Basic サービスは、インデクサー、データ ソース、およびスキルセットでの制限が低くなっています (15 ではなく 5)。
3 S3 HD サービスには、インデクサー サポートが含まれません。
4 スキルセットあたり最大 30 スキル。
5 AI エンリッチメントと画像分析は、コンピューティングを集中的に使用し、使用可能な処理能力を大量に消費します。 キュー内の他のジョブにも、より多くの実行の機会が与えられるように、これらのワークロードの実行時間は短縮されました。
6 インデクサーと組み合わせたインデクサー スキルセットの実行には、2 時間の最大期間が適用されます。 現在、一部のインデクサーでは、より長い 24 時間の最大実行期間が使用されますが、その動作は標準ではありません。 より長い期間は、サービスまたはそのインデクサーを内部で新しいランタイム動作に移行できない場合にのみ適用されます。 インデクサーまたはインデクサー スキルセット プロセスを完了するのに 2 時間を超える時間が必要な場合は、2 時間間隔で実行されるようにインデクサーをスケジュールします。
Note
「インデックスの制限」で説明したように、複合型をサポートする最新の GA API バージョン (2019-05-06) 以降では、ドキュメントごとのすべての複合コレクションに対する 3,000 要素の上限も、インデクサーによって適用されます。 つまり、以前のバージョンの API を使用してインデクサーを作成した場合、この制限の対象にはなりません。 最大の互換性を維持するために、以前のバージョンの API で作成され、API バージョン 2019-05-06 以降で更新されたインデクサーは、引き続き制限から除外されます。 前述のように、非常に大きな複合コレクションがあると、悪影響が生じることに注意する必要があります。最新の GA API バージョンを使用して、新しいインデクサーを作成することを強くお勧めします。
共有プライベート リンク リソースの制限
インデクサーでは、共有プライベート リンク リソース API を使用して管理されているプライベート エンドポイント経由で他の Azure リソースにアクセスできます。 このセクションでは、この機能に関連する制限について説明します。
| リソース | Free | 基本 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| プライベート エンドポイント インデクサーのサポート | いいえ | イエス | イエス | イエス | 有効 | No | イエス | はい |
| スキルセットがあるインデクサーのプライベート エンドポイントのサポート1 | いいえ | 番号 | 番号 | イエス | 有効 | No | イエス | はい |
| 最大プライベート エンドポイント | 該当なし | 10 または 30 | 100 | 400 | 400 | 該当なし | 20 | 20 |
| 個別のリソースの種類の最大数2 | 該当なし | 4 | 7 | 15 | 15 | 該当なし | 4 | 4 |
1 AI エンリッチメントと画像分析は、コンピューティングを集中的に使用し、使用可能な処理能力を大量に消費します。 このため、検索サービス自体のパフォーマンスと安定性に悪影響を及ぼさないように、下位層でプライベート接続は無効になっています。
2 個別のリソースの種類の数は、リソースの状態に関係なく、特定の検索サービスのすべての共有プライベート リンク リソースで使用される一意の groupId 値の数として計算されます。
シノニムの制限
シノニム マップの最大数は、レベルによって異なります。 各規則には最大 20 の拡張を含めることができます。ここで、拡張は同義語です。 たとえば、"cat" の場合、"kitty"、"feline"、および "felis" (ネコ属) との関連は、3 つの拡張としてカウントされます。
| リソース | Free | 基本 | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| シノニムマップの最大数 | 3 | 3 | 5 | 10 | 20 | 20 | 10 | 10 |
| マップごとの規則の最大数 | 5000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 |
インデックスの別名の上限
インデックスの別名の最大数は、レベルによって異なります。 いずれのレベルも、別名の最大数は許可されるインデックスの最大数の 2 倍です。
| リソース | Free | 基本 | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 最大別名 | 6 | 10 または 30 | 100 | 400 | 400 | パーティションあたり 2,000、またはサービスあたり 6,000 | 20 | 20 |
データの制限 (AI エンリッチメント)
エンティティ認識、エンティティリンク設定、キー フレーズの抽出、センチメント分析、言語選択、および個人情報検出の Azure AI Language リソースに対して呼び出しを行う AI エンリッチメント パイプラインは、データの制限を受ける可能性があります。 レコードのサイズは、String.Length で測定して 50,000 文字以下にする必要があります。 データをセンチメント アナライザーに送信する前に分割する必要がある場合は、テキスト分割スキルを使用します。
スロットル制限
システムがピーク時の容量に近づくにつれて、API 要求が調整されます。 スロットルの動作は API によって異なります。 クエリ API (検索/提案/オートコンプリート) とインデックス作成 API は、サービスの負荷に基づいて動的に調整されます。 インデックス API とサービス操作 API には、静的な要求レート制限があります。
インデックスに関連する操作の静的なレート要求の制限:
- インデックスの一覧取得 (GET /indexes): 1 秒あたり 3 件 (検索単位あたり)
- インデックスの取得 (GET /indexes/myindex): 1 秒あたり 10 件 (検索単位あたり)
- インデックスの作成 (POST /indexes): 1 秒あたり 12 件 (検索単位あたり)
- インデックスの作成または更新 (PUT /indexes/myindex): 1 秒あたり 6 件 (検索単位あたり)
- インデックスの削除 (DELETE /indexes/myindex): 1 秒あたり 12 件 (検索単位あたり)
サービスに関連する操作の静的なレート要求の制限:
- サービス統計情報 (GET /servicestats): 1 秒あたり 4 件 (検索単位あたり)
API 要求の制限
- 要求あたりの最大値: 16 MB1
- URL の最大長: 8 KB
- インデックスののアップロード、マージ、または削除のバッチあたりの最大ドキュメント数: 1,000
- $orderby 句の最大フィールド数: 32
- 検索句の最大文字数: 100,000 文字
search内の句の最大数 (AND または OR で 区切られた式): 1,024 個- 検索用語の最大サイズ: UTF-8 でエンコードされたテキストの 32,766 バイト (32 KB - 2 バイト)
- プレフィックス検索および正規表現検索での検索用語の最大サイズ: 1,000 文字
- Lucene によって処理される場合、ワイルドカード検索と正規表現検索で制御される状態の最大数: 1,000
1 Azure AI Search では、要求の本文に上限 16 MB が適用され、理論上の制限によって制限されない個々のフィールドまたはコレクションのコンテンツに実際的な制限が課されます (フィールドの構成と制限の詳細については、「 サポートされているデータ型 」を参照してください)。
無制限のクエリにより検索サービスが不安定になる恐れがあるため、クエリのサイズと構成に制限が適用されます。 通常、このようなクエリはプログラムによって生成されます。 アプリケーションがプログラムで検索クエリを生成する場合は、無制限のサイズのクエリが生成されないように設計することをお勧めします。
API 応答の制限
- 検索結果のページごとに返される最大ドキュメント数: 1,000
- 検索候補 API 要求ごとに返される最大検索候補数: 100
API キーの制限
API キーは、サービスの認証に使用されます。 次の 2 つの種類があります。 管理者キーは、要求ヘッダーで指定され、サービスに完全な読み取り/書き込みアクセス権を付与します。 クエリ キーは、読み取り専用で、URL で指定され、通常はクライアント アプリケーションに配布されます。
- サービスあたりの最大管理キー数: 2
- サービスあたりの最大クエリ キー数: 50