Azure AI Search のサービス制限
インデックスやその他のオブジェクトのストレージ、ワークロード、および数量の上限は、Azure AI 検索の作成を 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 個まで作成できます。 その後、同じサブスクリプションで合計 32 個の Basic サービスに加え、別のリージョンに 16 個の Basic サービスを作成できます。 レベルの詳細については、「Azure AI Search のレベル (または SKU) を選択する」を参照してください。
サービス数の上限は、依頼により引き上げが可能です。 同一のサブスクリプション内にさらに多くのサービスが必要な場合は、サポート リクエストを提出してください。
| リソース | Free 1 | 基本 | 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 つの無料検索サービスを使用できます。 無料レベルは、他の顧客と共有されるインフラストラクチャに基づいています。 ハードウェアは専用ではないため、スケールアップはサポートされておらず、ストレージは 50 MB に制限されています。 より多くのサービスを運用できるようにするため、無料の検索サービスは長時間非アクティブだと削除される可能性があります。
2 Search ユニット (SU) は、レプリカまたはパーティションのいずれかとして割り当てられている請求単位です。 両方が必要です。 SU の組み合わせの詳細については、「検索サービスの容量の見積もりと管理」を参照してください。
サービスの制限
次の表に、サービス レベルでの SLA、パーティション数、レプリカ数を示します。
| リソース | Free | 基本 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| サービス レベル アグリーメント (SLA) | いいえ | イエス | イエス | イエス | イエス | イエス | イエス | はい |
| メジャー グループ | 該当なし | 3 1 | 12 | 12 | 12 | 3 | 12 | 12 |
| レプリカ | 該当なし | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
1 Basic レベルでは、3 つのパーティションと 3 つのレプリカがサポートされ、2024 年 4 月 3 日以降に作成された新しい検索サービスでは合計 9 つの検索ユニット (SU) がサポートされます。 以前の Basic サービスでは、1 つのパーティションと 3 つのレプリカに制限されます。
検索サービスには、最大ストレージ制限 (パーティション サイズにパーティションの数を掛けたもの) またはインデックス または インデクサー の最大数のどちらか早い方のハード制限が適用されます。
サービス レベル保証 (SLA) は、クエリ ワークロードに 2 つ以上のレプリカを持つ課金対象サービス、またはクエリおよびインデックス作成ワークロードに 3 つ以上のレプリカを持つ課金対象サービスに適用されます。 パーティション数は SLA には関係ありません。 詳細については、「Azure AI Search の信頼性」を参照してください。
無料サービスには固定パーティションやレプリカはなく、他のサブスクライバーとリソースを共有します。
パーティション ストレージ (GB)
サービスごとのストレージ制限は、サービスの作成日とリージョンの 2 つの要素によって異なります。 サポートされているほとんどのリージョンでは、サービスが新しいほど制限が高くなります。
次の表は、時間の経過に伴うストレージ クォータの増加の進行状況を GB 単位で示しています。 2024 年 4 月から、脚注に記載されているリージョンで、より大きな容量のパーティションがオンライン化されました。 より大きな容量は、新規の検索サービスに限定されます。 現時点では、インプレース アップグレードはありません。
| サービスの作成日 | 基本 | S1 | S2 | S3/HD | L1 | L2 |
|---|---|---|---|---|---|---|
| 2024 年 4 月 3 日以前 | 2 | 25 | 100 | 200 | 1,024 | 2,048 |
| 2024 年 4 月 3 日から 2024 年 5 月 17 日まで 1 | 15 | 160 | 512 | 1,024 | 1,024 | 2,048 |
| 2024 年 5 月 17 日以降 2 | 15 | 160 | 512 | 1,024 | 2,048 | 4,096 |
1 これらのリージョン内の Basic、S1、S2、S3 用のより大きな容量のストレージ。 南北アメリカ: ブラジル南部、カナダ中部、カナダ東部、米国東部、米国東部 2、米国中部、米国中北部、米国中南部、米国西部、米国西部 2、米国西部 3、米国中西部。 ヨーロッパ: フランス中部。 イタリア北部、北ヨーロッパ、ノルウェー東部、ポーランド中部、スイス北部、スウェーデン中部、英国南部、英国西部。 中東: アラブ首長国連邦北部。 アフリカ: 南アフリカ北部。 アジア太平洋: オーストラリア東部、オーストラリア南東部、インド中部、Jio インド西部、東アジア、東南アジア、東日本、西日本、韓国中部、韓国南部。
2 L1 および L2 用のより大きな容量のストレージ。 すべての課金対象レベルでより大きな容量を提供するリージョンが増加しています。 ヨーロッパ: ドイツ北部、ドイツ中西部、スイス西部。 Azure Government: テキサス、アリゾナ、バージニア。 アフリカ: 南アフリカ北部。 アジア太平洋: 中国北部 3、中国東部 3。
4 月 3 日の制限に従って、いくつかのリージョンは引き続き古いインフラストラクチャで実行されます。 新しいサービスを作成する前に、サポートされているリージョンを確認し、選択したリージョンで追加の容量が提供されていることを確認します。
インデックスの制限
| リソース | 制限なし | 基本 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 |
| ベクトル フィールドあたりの最大ディメンション | 4098 | 4098 | 4098 | 4098 | 4098 | 4098 | 4098 | 4098 |
| インデックスあたりの複合コレクション フィールドの最大数 | 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 |
| 最大インデックス サイズ 4 | 該当なし | 該当なし | 該当なし | 1.88 TB | 2.34 TB | 100 GB | 該当なし | 該当なし |
1 2017 年 12 月より前に作成された Basic サービスは、インデックスでの制限が低くなっています (15 ではなく 5)。 Basic レベルにのみ下限（インデックスあたり 100 フィールド）があります。
2 フィールドの上限には、複合コレクション内の第 1 レベルのフィールドと入れ子になったサブフィールドの両方が含まれます。 たとえば、インデックスに 15 個のフィールドが含まれており、それぞれ 5 つのサブフィールドを持つ 2 つの複合コレクションがある場合、インデックスのフィールド数は 25 になります。 フィールド コレクションが非常に大きい場合、インデックスの処理速度が低下する場合があります。 フィールドと属性を必要なものだけに制限し、インデックス作成とクエリ テストを実行して、パフォーマンスが許容できることを確認します。
3 多数の要素があると、インデックスに必要なストレージは大幅に増えるため、要素には上限があります。 複合コレクションの要素は、そのコレクションのメンバーとして定義されます。 たとえば、部屋の複合コレクションが記載されているホテル ドキュメントがあるとします。部屋コレクション内の各部屋は、1 つの要素として見なされます。 インデックス作成時は、インデックス作成エンジンによって、ドキュメント全体で最大 3,000 の要素が安全に処理されます。 この制限は api-version=2019-05-06 で導入され、文字列コレクションや複合フィールドではなく、複合コレクションにのみ適用されます。
4 ほとんどのレベルで、インデックスの最大サイズは、検索サービスで使用可能なすべてのストレージです。 S2、S3、S3 HD の場合、インデックスの最大サイズは、表に指定された数です。 2024 年 4 月 3 日以降に作成された検索サービスに適用されます。
サービスがより強力なクラスターでプロビジョニングされている場合は、上限に多少の違いがあることがあります。 ここでの制限は、共通の分母を表します。 上記の仕様に基づいて構築されたインデックスは、任意のリージョンの同等のサービス レベル間で移植できます。
ドキュメントの制限
以下は、インデックスあたりのドキュメントの最大数です。
- Basic、S1、S2、S3 で 240 億
- S3 HD で 20 億
- L1 で 2,880 億
- L2 で 5,760 億
制限に関しては、複合コレクションの各インスタンスは個別のドキュメントとしてカウントされます。
各ドキュメントの最大サイズは、約 16 メガバイトです。 ドキュメント サイズは、実際にはインデックス作成 API 要求ペイロードのサイズ (16 メガバイト) の制限です。 そのペイロードは、1 つのドキュメントまたはドキュメントのバッチである可能性があります。 バッチ内のドキュメントが 1 つの場合、最大ドキュメント サイズは JSON 形式で 16 MB です。
ドキュメント サイズは、ドキュメントを検索サービスにアップロードする "プッシュ モード" のインデックス作成に適用されます。 "プル モード" のインデックス作成にインデクサーを使用している場合は、インデクサー制限に従って、ソース ファイルを任意のファイル サイズにできます。 BLOB インデクサーの場合、上位レベルでは、ファイル サイズの制限は大きくなります。 たとえば、S1 の制限は 128 メガバイト、S2 の制限は 256 メガバイトなどです。
ドキュメントのサイズを見積もるときは、検索シナリオにとって価値のあるフィールドのみにインデックス付けし、実行するクエリで用途のないソース フィールドは除外することを忘れないでください。
ベクトル インデックス サイズの制限
ベクトル フィールドを使用してドキュメントにインデックスを作成する場合、指定したアルゴリズム パラメーターを使い、Azure AI Search によって内部ベクトル インデックスが構築されます。 これらのベクトル インデックスのサイズは、サービスのレベル (または SKU) のベクトル検索用に予約されたメモリによって制限されます。 ベクトル ストレージの管理と最大化に関するガイダンスについては、「ベクトル インデックスのサイズと制限以下の維持」を参照してください。
ベクトルの制限は以下によって異なります。
2024 年 4 月以降、追加のキャパシティが提供されるリージョン (大半のリージョン) の新しい検索サービスでは、より高いベクトル制限が存在します。
次の表は、時間の経過と共に増加するベクトル クォータの進行を GB で示しています。 クォータはパーティションごとであるため、新しい Standard (S1) サービスを 6 つのパーティションにスケーリングすると、ベクトル クォータの合計は 35 に 6 を乗算したものになります。
| サービスの作成日 | 基本 | S1 | S2 | S3/HD | L1 | L2 |
|---|---|---|---|---|---|---|
| 2023 年 7 月 1 日より前 1 | 0.5 | 1 | 6 | 12 | 12 | 36 |
| 2023 年 7 月 1 日から 2024 年 4 月 3 日まで 2 | 1 | 3 | 12 | 36 | 12 | 36 |
| 2024 年 4 月 3 日から 2024 年 5 月 17 日まで 3 | 5 | 35 | 150 | 300 | 12 | 36 |
| 2024 年 5 月 17 日以降 4 | 5 | 35 | 150 | 300 | 150 | 300 |
1 初期プレビュー中の初期ベクトル制限。
2 後期プレビュー期間中の 2 つのベクトル制限。 ドイツ中西部、インド西部、カタール中部の 3 つのリージョンには、より高い制限はありませんでした。
3 サポートされているレベルとリージョンにおけるより大きなパーティションに基づいた、より高いベクトル クォータ。
4 パーティション サイズの更新に基づいた、より多くのレベルとリージョンにおけるより高いベクトル クォータ。
このサービスでは、検索サービス内のすべてのパーティションに対して、ベクトル インデックス サイズのクォータ が適用されます。 追加パーティションごとに、使用可能なベクトル インデックス サイズのクォータが増加します。 このクォータは、サービスが正常な状態を保つためのハード制限です。つまり、制限を超えてインデックスを作成しようとすると、エラーが発生します。 一部のベクトル ドキュメントを削除するか、パーティションでスケールアップを行うことで、使用可能なクォータを解放すれば、インデックス作成を再開できます。
重要
ベクトル制限が大きいほど、大きなパーティション サイズに関連付けられます。 引き続き古いインフラストラクチャで実行されるリージョンは、7 月から 4 月の制限に従います。 パーティション ストレージ制限の状態については、リージョンの一覧を確認してください。
インデクサー制限
サービスに全体としてのバランスと安定性を提供するために、最大実行時間が設けられていますが、より大規模なデータ セットでは、許可されている最大値よりも長いインデックス作成時間が必要になることがあります。 インデックス作成ジョブを最大許容時間内を完了できない場合は、スケジュールで実行してみてください。 スケジューラはインデックスの状態を追跡します。 スケジュールされたインデックス作成ジョブが何らかの理由で中断された場合、インデクサーは、次のスケジュールされた実行時に最後の終了状態を選択できます。
| リソース | Free 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 分 |
| 最大実行時間 5 | 1-3 分または 3-10 分 | 2 または 24 時間 | 2 または 24 時間 | 2 または 24 時間 | 2 または 24 時間 | 該当なし | 2 または 24 時間 | 2 または 24 時間 |
| BLOB インデクサー: BLOB の最大サイズ、MB | 16 | 16 | 128 | 256 | 256 | 該当なし | 256 | 256 |
| BLOB インデクサー: BLOB から抽出されたコンテンツの最大文字数 6 | 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 インデクサーの最大期間の 2 時間または 24 時間について: 最長 2 時間が最も一般的であり、それに合わせて計画することをお勧めします。 これは、パブリック環境で実行されるインデクサーを指します。計算負荷の高い処理をオフロードし、クエリ用により多くのリソースを残すために使用されます。 24 時間の制限は、検索サービスに割り当てられているインフラストラクチャのみを使用してプライベート環境で実行するようにインデクサーを構成する場合に適用されます。 一部の古いインデクサーはパブリック環境では実行できず、それらのインデクサーには常に 24 時間の処理範囲があることに注意してください。 スケジュールされていないインデクサーが 24 時間継続的に実行されている場合、それらのインデクサーは、新しいインフラストラクチャに移行できなかったと見なせます。 一般的なルールとして、2 時間以内に終了できないジョブのインデックス作成では、インデクサーを 5 分のスケジュール に配置して、インデクサーが中断した場所をすばやく取得できるようにします。 Free レベルでは、3-10 分という最大実行時間はスキルセットを持つインデクサーに対するものです。
6 最大文字数は Unicode コード単位 (特に UTF-16) に基づいています。
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 |
|---|---|---|---|---|---|---|---|---|
| プライベート エンドポイント インデクサーのサポート | いいえ | イエス | イエス | イエス | はい | いいえ | イエス | はい |
| スキルセットがあるインデクサーのプライベート エンドポイントのサポート1 | いいえ | いいえ | 番号 | イエス | はい | いいえ | イエス | はい |
| スキルセットと垂直統合があるインデクサーのプライベート エンドポイントのサポート2 | いいえ | イエス | イエス | イエス | はい | いいえ | イエス | はい |
| 最大プライベート エンドポイント | 該当なし | 10 または 30 | 100 | 400 | 400 | 該当なし | 20 | 20 |
| 個別のリソースの種類の最大数3 | 該当なし | 4 | 7 | 15 | 15 | 該当なし | 4 | 4 |
1 AI エンリッチメントと画像分析は、コンピューティングを集中的に使用し、使用可能な処理能力を大量に消費します。 このため、検索サービス自体のパフォーマンスと安定性を確保するために、下位レベルではプライベート接続が無効になっています。
22024 年 4 月 3 日以降にパーティション ストレージに記載されているリージョンで作成された大容量サービスと、インデックス作成時に実行される垂直統合のワークロードでは、有料レベルの共有プライベート リンクがサポートされます。 システムは、少なくともデータを埋め込むスキルを検出する必要があります。
3個別のリソースの種類の数は、リソースの状態に関係なく、特定の検索サービスのすべての共有プライベート リンク リソースで使用される一意の 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 |
インデックスの別名の上限
インデックスの別名の最大数は、レベルとサービスの作成日によって異なります。 いずれのレベルでも、2022 年 10 月以降に作成されたサービスの場合、別名の最大数は許可されるインデックスの最大数の 2 倍です。 2022 年 10 月より前に作成されたサービスの場合、制限は許可されるインデックスの数です。
| サービスの作成日 | Free | 基本 | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 2022 年 10 月より前 | 3 | 5 または 15 1 | 50 | 200 | 200 | パーティションあたり 1,000、またはサービスあたり 3,000 | 10 | 10 |
| 2022 年 10 月以降 | 6 | 30 | 100 | 400 | 400 | パーティションあたり 2,000、またはサービスあたり 6,000 | 20 | 20 |
1 2017 年 12 月より前に作成された Basic サービスは、インデックスに対する制限が低くなっています (15 ではなく 5)
データの制限 (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 件 (検索単位あたり)
セマンティック ランカーのスロットリング制限
セマンティック ランカーは、キュー システムを使って同時要求を管理します。 このシステムにより、検索サービスは 1 秒あたりのクエリ数を可能な限り高くできます。 同時要求の制限に達すると、それ以上の要求はキューに配置されます。 キューがいっぱいになった場合、それ以降の要求は拒否され、再試行する必要があります。
セマンティック ランカーの 1 秒あたりの合計クエリ数は、次の要因によって変化します。
- 検索サービスのレベル。 キューの容量と同時要求の制限はどちらもレベルによって異なります。
- 検索サービス内の検索ユニットの数。 セマンティック ランカーの同時クエリの最大数を増やす最も簡単な方法は、検索サービスに検索ユニットをさらに追加することです。
- リージョンでのセマンティック ランカーの合計使用可能容量。
- セマンティック ランカーを使ってクエリを処理するのにかかる時間。 これは、検索サービスのビジー状態によって変わります。
次の表では、リージョンで使用可能な容量に応じて、レベルごとのセマンティック ランカー調整の制限について説明します。 制限の引き上げを要求するには、Microsoft サポートにお問い合わせください。
| リソース | 基本 | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|
| 最大同時要求数 (検索ユニットごと) | 2 | 3 | 4 | 4 | 4 | 4 | 4 |
| 最大要求キュー サイズ (検索ユニットごと) | 4 | 6 | 8 | 8 | 8 | 8 | 8 |
API 要求の制限
無制限のクエリは検索サービスを不安定にする可能性があるため、クエリの制限が存在します。 通常、このようなクエリはプログラムによって生成されます。 アプリケーションがプログラムで検索クエリを生成する場合は、無制限のサイズのクエリが生成されないように設計することをお勧めします。
ペイロードの制限も同様の理由で存在するため、検索サービスの安定性が確保されます。 この制限は、要求全体 (すべてのコンポーネントを含む) に適用されます。 たとえば、要求が複数のドキュメントまたはコマンドをバッチ処理する場合、要求全体がサポートされる制限内に収まる必要があります。
サポートされている制限を超える必要がある場合は、ワークロードをテストして、期待される内容を把握する必要があります。
特記された場合を除き、次の API 要求は、Azure SDK を含むすべてのプログラミング可能なインターフェイスに適用されます。
全般:
- サポートされている最大ペイロード制限は、REST API と SDK を使用したインデックス作成とクエリ要求に対して 16 MB です。
- 最大 8 KB の URL 長 (REST API のみに適用)。
インデックス作成 API:
- サポートされているインデックスののアップロード、マージ、または削除のバッチあたりの最大ドキュメント数: 1,000。
クエリ API:
- $orderby 句の最大フィールド数: 32。
- 検索句の最大文字数: 100,000 文字。
- 検索内の句の最大数は 3,000 です。
- Lucene によって適用される、ワイルドカード と 正規表現 クエリの上限。 パターン、バリエーション、または一致するインスタンスの数が 1,000 個に制限されます。 この制限は、エンジンの過負荷を回避するために設定されています。
検索語句:
- サポートされている検索用語の最大サイズ: UTF-8 でエンコードされたテキストの 32,766 バイト (32 KB - 2 バイト)。 キーワード検索とベクトル検索の text プロパティに適用されます。
- サポートされているプレフィックス検索および正規表現検索での検索用語の最大サイズ: 1,000 文字。
API 応答の制限
- 検索結果のページごとに返される最大ドキュメント数: 1,000
- 検索候補 API 要求ごとに返される最大検索候補数: 100
検索エンジンは既定で 50 件の結果を返しますが、このパラメーターを最大制限にオーバーライドできます。
API キーの制限
API キーは、サービスの認証に使用されます。 次の 2 つの種類があります。 管理者キーは、要求ヘッダーで指定され、サービスに完全な読み取り/書き込みアクセス権を付与します。 クエリ キーは、読み取り専用で、URL で指定され、通常はクライアント アプリケーションに配布されます。
- サービスあたりの最大管理キー数: 2
- サービスあたりの最大クエリ キー数: 50