Azure AI 검색의 서비스 제한 사항
스토리지, 워크로드 및 인덱스, 기타 개체의 수량에 대한 최대 제한은 Azure AI 검색을 무료, 기본, 표준 또는 스토리지 최적화 가격 책정 계층 중 어디에 만드는지에 따라 달라집니다.
무료은(는) Azure 구독과 함께 제공되는 다중 테넌트 공유 서비스입니다.
기본은 프로덕션 워크로드 전용 컴퓨팅 리소스를 더 작은 규모로 제공하지만 일부 네트워킹 인프라를 다른 테넌트와 공유합니다.
표준은 모든 수준에서 더 많은 스토리지 및 처리 용량으로 전용 컴퓨터에서 실행됩니다. 표준은 4가지 수준인 S1, S2, S3 및 S3 HD로 제공됩니다. S3 HD(S3 고밀도)는 멀티 테넌트 및 대량의 소규모 인덱스(서비스당 인덱스 3,000개)을 위해 설계되었습니다. S3 HD는 인덱서 기능을 제공하지 않으며 데이터 수집은 원본에서 인덱스로 데이터를 푸시하는 API를 사용해야 합니다.
스토리지 최적화는 표준보다 많은 총 스토리지, 스토리지 대역폭 및 메모리가 있는 전용 머신에서 실행됩니다. 이 계층은 느리게 변경되는 대량 인덱스를 대상으로 합니다. 스토리지 최적화는 L1 및 L2의 두 가지 수준으로 제공됩니다.
구독 제한
각 계층에 허용되는 최대 서비스 수까지 여러 개의 청구 가능한 검색 서비스(기본 이상)를 만들 수 있습니다. 예를 들어, 기본 계층에 최대 16개의 서비스를 만들고, 동일한 구독 내의 S1 계층에 16개의 다른 서비스를 만들 수 있습니다. 계층에 대한 자세한 내용은 Azure AI 검색에 대한 계층(또는 SKU) 선택을 참조하세요.
최대 서비스 제한은 요청 시 설정할 수 있습니다. 동일한 구독 내에서 더 많은 서비스가 필요한 경우 지원 요청을 제출합니다.
| 리소스 | 무료 1 | 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 구독당 하나의 무료 검색 서비스를 사용할 수 있습니다. 무료 계층은 다른 고객과 공유되는 인프라를 기반으로 합니다. 하드웨어는 전용이 아니므로 스케일 업이 지원되지 않으며 스토리지는 50MB로 제한됩니다.
2 SU(검색 단위)는 복제본 또는 파티션으로 할당되는 청구 가능 단위입니다. 둘 다 필요합니다. SU 조합에 대해 자세히 알아보려면 검색 서비스 용량 예측 및 관리를 참조하세요.
서비스 제한
스토리지, 파티션, 복제본에 대한 검색 서비스 한도는 서비스 만든 날짜에 따라 다르며, 지원되는 지역의 최신 서비스에 대한 한도는 더 높습니다.
검색 서비스에는 최대 저장 한도(파티션 크기에 파티션 수를 곱함) 또는 최대 인덱스 수 또는 인덱서에 대한 엄격한 제한 중 먼저 도래하는 제한이 적용됩니다.
SLA(서비스 수준 계약)는 쿼리 워크로드용 복제본이 2개 이상 있거나 쿼리 및 인덱싱 워크로드용 복제본이 3개 이상 있는 청구 가능 서비스에 적용됩니다. 파티션의 수는 SLA 고려사항이 아닙니다. 자세한 내용은 Azure AI 검색의 안정성을 참조하세요.
무료 서비스에는 고정된 파티션이나 복제본이 없으며 다른 구독자와 리소스를 공유합니다.
2024년 4월 3일 이전
| 리소스 | 무료 | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| SLA(서비스 수준 약정) | 예 | 예 | 네 | 네 | 네 | 네 | 네 | 예 |
| 스토리지(파티션 크기) | 50MB | 2GB | 25GB | 100GB | 200GB | 200GB | 1TB | 2TB |
| 파티션 | 해당 없음 | 1 | 12 | 12 | 12 | 3 | 12 | 12 |
| 복제본 | 해당 없음 | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
2024년 4월 3일 이후
2024년 4월 3일 이후에 만들어진 새로운 서비스의 경우:
- 기본 계층에는 최대 3개의 파티션과 3개의 복제본, 총 9개의 SU(검색 단위)가 있을 수 있습니다.
- 기본, S1, S2, S3은 계층에 따라 3~7배 더 많은 파티션당 더 많은 스토리지를 제공합니다.
- 기본 및 기타 계층에 대한 추가 용량을 가져오려면 새 검색 서비스가 지원되는 지역에 있어야 합니다.
지금은 현재 위치 업그레이드가 없습니다. 추가 스토리지를 활용하려면 새 검색 서비스를 만들어야 합니다.
| 리소스 | 무료 | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| SLA(서비스 수준 약정) | 예 | 예 | 네 | 네 | 네 | 네 | 네 | 예 |
| 스토리지(파티션 크기) | 50MB | 15GB | 160GB | 350GB | 700GB | 700GB | 1TB | 2TB |
| 파티션 | 해당 없음 | 3 | 12 | 12 | 12 | 3 | 12 | 12 |
| 복제본 | 해당 없음 | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
저장 한도가 더 높은 지원 지역
추가 스토리지를 가져오려면 2024년 4월 3일 이후에 만들어진 서비스가 다음 지역 중 하나에 있어야 합니다. 다른 지역으로의 확장에 대해서는 Azure AI 검색의 새로운 기능에서 공지 사항을 확인합니다.
| 국가 | 파티션당 추가 용량을 제공하는 지역 |
|---|---|
| 미국 | 미국 동부, 미국 동부 2, 미국 중부, 미국 중북부, 미국 중남부, 미국 서부, 미국 서부 2, 미국 서부 3, 미국 중서부 |
| 영국 | 영국 남부, 영국 서부 |
| 아랍에미리트연합국 | 아랍에미리트 북부 |
| 스위스 | 스위스 서부 |
| 스웨덴 | 스웨덴 중부 |
| 폴란드 | 폴란드 중부 |
| 노르웨이 | 노르웨이 동부 |
| 한국 | 한국 중부, 한국 남부 |
| 일본 | 일본 동부, 일본 서부 |
| 이탈리아 | 이탈리아 북부 |
| 인도 | 인도 중부, Jio 인도 서부 |
| 프랑스 | 프랑스 중부 |
| 유럽 | 북유럽 |
| 캐나다 | 캐나다 중부, 캐나다 동부 |
| 바질 | 브라질 남부 |
| 아시아 태평양 | 동아시아, 동남 아시아 |
| 오스트레일리아 | 오스트레일리아 동부, 오스트레일리아 남동부 |
인덱스 제한
| 리소스 | Free | 기본 1 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 최대 인덱스 | 3 | 5 또는 15 | 50 | 200 | 200 | 파티션당 1000 또는 서비스당 3000 | 10 | 10 |
| 인덱스당 최대 단순 필드 2 | 1000 | 100 | 1000 | 1000 | 1000 | 1000 | 1000 | 1000 |
| 벡터 필드당 최대 크기 | 3072 | 3072 | 3072 | 3072 | 3072 | 3072 | 3072 | 3072 |
| 인덱스당 최대 복합 컬렉션 | 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.92TB | 2.4TB | 100GB | 해당 없음 | 해당 없음 |
1 2017년 12월 이전에 생성된 기본 서비스는 인덱스에서 낮은 제한(15 대신 5)을 갖습니다. 기본 계층은 인덱스당 100개 필드 제한보다 더 낮은 유일한 계층입니다.
2 필드의 상한에는 복합 컬렉션의 첫 번째 수준 필드와 중첩된 하위 필드가 모두 포함됩니다. 예를 들어 인덱스에 15개의 필드가 있고 각각 5개의 하위 필드가 있는 2개의 복합 컬렉션이 있는 경우 인덱스의 필드 수는 25입니다. 필드 컬렉션이 매우 큰 인덱스는 느릴 수 있습니다. 필드와 특성을 필요한 것으로 제한하고 인덱싱 및 쿼리 테스트를 실행하여 성능이 적합한지 확인합니다.
3 요소 수가 많으면 인덱스에 필요한 스토리지가 크게 증가하므로 요소에 대한 상한이 있습니다. 복합 컬렉션의 요소는 해당 컬렉션의 멤버로 정의됩니다. 예를 들어 객실 복합 컬렉션이 있는 호텔 문서를 가정하면 객실 컬렉션의 각 객실은 요소로 간주됩니다. 인덱싱 중에 인덱싱 엔진은 문서 전체에서 최대 3000개의 요소를 안전하게 처리할 수 있습니다. 이 제한은 api-version=2019-05-06에서 도입되었으며, 문자열 컬렉션이나 복합 필드에는 적용되지 않고 복합 컬렉션에만 적용됩니다.
4 대부분의 계층에서 최대 인덱스 크기는 검색 서비스에서 사용 가능한 모든 스토리지입니다. S2, S3, S3 HD의 경우 인덱스의 최대 크기는 표에 제공된 숫자입니다. 2024년 4월 3일 이후 만들어진 검색 서비스에 적용됩니다.
서비스가 더 강력한 클러스터에서 프로비전되는 경우 최대 제한에 다소 차이가 있을 수 있습니다. 여기서 제한은 공통 분모를 나타냅니다. 위의 사양에 따라 빌드된 인덱스는 모든 지역의 동등한 서비스 계층에서 이식할 수 있습니다.
문서 제한
Basic, S1, S2, S3, L1 및 L2 검색 서비스에서 인덱스당 약 240억 개의 문서를 보유할 수 있습니다. S3 HD의 경우 제한은 인덱스당 20억 개 문서입니다. 복합 컬렉션의 각 인스턴스는 이러한 제한을 기준으로 개별 문서로 계산됩니다.
API 호출당 문서 크기 제한
인덱스 API를 호출할 때 최대 문서 크기는 약 16MB입니다.
문서 크기는 실제로 인덱스 API 요청 본문의 크기를 제한합니다. 여러 문서를 포함하는 배치를 한꺼번에 인덱스 API에 전달할 수 있으므로 현실적으로 크기 제한은 배치에 포함된 문서 수에 따라 좌우됩니다. 단일 문서를 포함하는 배치의 경우 최대 문서 크기는 16MB의 JSON입니다.
문서 크기를 추정하는 경우 검색 서비스에서 사용할 수 있는 필드만 고려해야 합니다. 원본 문서의 모든 이진 또는 이미지 데이터는 계산에서 생략해야 합니다.
벡터 인덱스 크기 제한
벡터 필드로 문서를 인덱싱할 때 Azure AI 검색은 사용자가 제공하는 알고리즘 매개 변수를 사용하여 내부 벡터 인덱스를 구성합니다. 이러한 벡터 인덱스의 크기는 서비스 계층(또는 SKU)의 벡터 검색을 위해 예약된 메모리에 의해 제한됩니다.
서비스는 검색 서비스의 모든 파티션에 대해 벡터 인덱스 크기 할당량을 적용합니다. 각각의 추가 파티션은 사용 가능한 벡터 인덱스 크기 할당량을 늘립니다. 이 할당량은 서비스를 정상 상태로 유지하기 위한 엄격한 제한입니다. 즉, 제한을 초과하면 추가 인덱싱 시도가 실패하게 됩니다. 일부 벡터 문서를 삭제하거나 파티션에서 확장하여 사용 가능한 할당량을 확보한 후 인덱싱을 재개할 수 있습니다.
이 표에서는 서비스 계층의 파티션당 벡터 인덱스 크기 할당량에 대해 설명합니다. 컨텍스트의 경우 다음이 포함됩니다.
- 각 계층에 대한 파티션 저장 한도는 컨텐스트에 대해 여기에서 반복됩니다.
- 벡터 인덱스에 사용할 수 있는 각 파티션 크기(GB)입니다(인덱스에 벡터 필드를 추가할 때 생성됨).
- 파티션당 대략적인 포함 수(부동 소수점 값)입니다.
서비스 통계 가져오기를 사용하여 벡터 인덱스 크기 할당량을 검색하거나 Azure Portal에서 인덱스 페이지 또는 사용량 탭을 검토합니다.
벡터 제한은 서비스 만든 날짜 및 계층에 따라 다릅니다. 검색 서비스의 수명을 확인하고 벡터 인덱스에 대해 자세히 알아보려면 벡터 인덱스 크기 및 한도 준수를 참조하세요.
지원되는 지역에서 2024년 4월 3일 이후에 만들어진 서비스에 대한 벡터 제한
지원되는 지역에서 2024년 4월 3일 이후에 만들어진 검색 서비스에는 가장 높은 벡터 제한이 적용됩니다.
| 계층 | 스토리지 할당량(GB) | 파티션당 벡터 할당량(GB) | 파티션당 대략적인 부동 소수 자릿수(오버헤드 15% 가정) |
|---|---|---|---|
| 기본 | 15 | 5 | 11억 |
| S1 | 160 | 35 | 82억 |
| S2 | 350 | 100 | 235억 |
| S3 | 700 | 200 | 470억 |
| L1 | 1,000 | 12 | 28억 |
| L2 | 2,000 | 36 | 84억 |
4월 3일 출시에서는 L1 및 L2 제한이 변경되지 않았습니다.
2023년 7월 1일부터 2024년 4월 3일 사이에 만들어진 서비스에 대한 벡터 제한
2023년 7월 1일 이전에 원래 제한이 있었던 다음 지역을 제외하고 2024년 7월 1일부터 4월 3일 사이에 만들어진 새 서비스에는 다음 제한이 적용됩니다.
- 독일 중서부
- 인도 서부
- 카타르 중부
다른 모든 지역에는 다음과 같은 제한이 있습니다.
| 계층 | 스토리지 할당량(GB) | 파티션당 벡터 할당량(GB) | 파티션당 대략적인 부동 소수 자릿수(오버헤드 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억 |
2023년 7월 1일 이전에 만들어진 서비스에 대한 벡터 제한
| 계층 | 스토리지 할당량(GB) | 파티션당 벡터 할당량(GB) | 파티션당 대략적인 부동 소수 자릿수(오버헤드 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억 |
인덱서 제한
최대 실행 시간은 서비스에 대한 균형 및 안정성을 제공하기 위해 존재하지만 큰 데이터 세트는 최대 허용보다 많은 인덱싱 시간이 필요할 수 있습니다. 인덱싱 작업이 허용된 최대 시간 내에 완료될 수 없는 경우에는 일정에 따라 실행해 보세요. 스케줄러는 인덱싱 상태를 추적합니다. 어떤 이유로든 예약된 인덱싱 작업이 중단되면 다음에 예약된 실행에서 인덱서가 지난 번에 중단된 위치부터 작업을 이어갈 수 있습니다.
| 리소스 | 무료 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분 | 2시간 또는 24시간 | 2시간 또는 24시간 | 2시간 또는 24시간 | 2시간 또는 24시간 | 해당 없음 | 2시간 또는 24시간 | 2시간 또는 24시간 |
| 기술 세트가 있는 인덱서의 최대 실행 시간 6 | 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 무료 계층의 인덱서 최대 실행 시간은 Blob 원본의 경우 3분이고 기타 모든 데이터 원본의 경우 1분입니다. 인덱서 호출은 180초마다 한 번입니다. Azure AI Services를 호출하는 AI 인덱싱의 경우 무료 서비스는 매일 인덱스당 20개의 무료 트랜잭션으로 제한되며, 여기서 트랜잭션은 보강 파이프라인을 통해 성공적으로 전달되는 문서로 정의됩니다(팁: 인덱서를 재설정하여 카운트를 재설정할 수 있음).
2 2017년 12월 이전에 생성된 기본 서비스는 인덱스, 데이터 원본 및 기술 세트에서 낮은 제한(15 대신 5)을 갖습니다.
3 S3 HD 서비스는 인덱서 지원을 포함하지 않습니다.
4 기술 집합당 최대 30개의 기술입니다.
5 인덱서의 최대 기간은 2시간 또는 24시간입니다. 최대 2시간이 가장 일반적이며 이를 계획해야 합니다. 24시간 제한은 이전 인덱서 구현에서 가져옵니다. 24시간 동안 지속적으로 실행되는 예약되지 않은 인덱서가 있는 경우 해당 인덱서를 최신 인프라로 마이그레이션할 수 없기 때문입니다. 일반적으로 2시간 이내에 완료할 수 없는 인덱싱 작업의 경우 인덱서를 2시간 일정으로 설정합니다. 처음 2시간 간격이 완료되면 인덱서는 다음 2시간 간격을 시작할 때 중단된 지점을 선택합니다.
6 기술 세트 실행, 특히 이미지 분석은 계산 집약적이며 사용 가능한 처리 능력을 과도하게 많이 소비합니다. 이러한 워크로드에 대한 실행 시간이 단축되어 큐의 다른 작업을 실행하는 데 더 많은 기회를 제공합니다.
참고 항목
인덱스 제한에 설명된 것처럼 인덱서는 복합 형식(2019-05-06)을 지원하는 최신 GA API 버전부터 문서당 모든 복합 컬렉션에 대해 3000 요소의 상한을 적용합니다. 즉, 이전 API 버전을 사용하여 인덱서를 만든 경우에는 이 제한이 적용되지 않습니다. 최대 호환성을 유지하려면 이전 API 버전을 사용하여 만든 다음, 2019-05-06 이상의 API 버전으로 업데이트된 인덱서는 여전히 제한에서 제외됩니다. 고객은 앞에서 설명한 것처럼 매우 큰 복합 컬렉션을 사용하는 경우 부정적인 영향에 대해 알고 있어야 하며 최신 GA API 버전을 사용하여 새 인덱서를 만드는 것이 좋습니다.
공유 프라이빗 링크 리소스 제한
인덱서는 공유 프라이빗 링크 리소스 API를 통해 관리되는 프라이빗 엔드포인트를 통해 다른 Azure 리소스에 액세스할 수 있습니다. 이 섹션에서는 이 기능과 관련된 제한 사항을 설명합니다.
| 리소스 | 무료 | Basic | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 프라이빗 엔드포인트 인덱서 지원 | 예 | 예 | 네 | 네 | 네 | 없음 | 예 | 예 |
| 기술 세트가 있는 인덱서를 위한 프라이빗 엔드포인트 지원 1 | 아니요 | 아니요 | 아니요 | 예 | 네 | 없음 | 예 | 예 |
| 최대 프라이빗 엔드포인트 | 해당 없음 | 10 또는 30 | 100 | 400 | 400 | 해당 없음 | 20 | 20 |
| 최대 고유 리소스 유형2 | 해당 없음 | 4 | 7 | 15 | 15 | 해당 없음 | 4 | 4 |
1 AI 보강 및 이미지 분석은 계산 집약적이며 사용 가능한 처리 능력을 과도하게 많이 소비합니다. 이러한 이유로 검색 서비스 자체의 성능 및 안정성을 보장하도록 하위 계층에서는 프라이빗 연결을 사용하지 않도록 설정합니다.
2 고유한 리소스 형식 수는 리소스의 상태에 관계없이 지정된 검색 서비스에 대한 모든 공유 프라이빗 링크 리소스에서 사용되는 고유한 groupId 값의 수로 계산됩니다.
동의어 제한
동의어 맵의 최대 개수는 계층에 따라 다릅니다. 각 규칙에는 최대 20개의 확장이 있을 수 있습니다. 여기서 확장은 동일한 용어입니다. 예를 들어, "kitty", "feline" 및 "felis"(고양이 속)와 연결된 "cat"은 3개의 확장으로 계산됩니다.
| 리소스 | 무료 | Basic | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 최대 동의어 맵 | 3 | 3 | 5 | 10 | 20 | 20 | 10 | 10 |
| 맵당 최대 규칙 수 | 5000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 |
인덱스 별칭 제한
인덱스 별칭의 최대 수는 계층에 따라 다릅니다. 모든 계층에서 최대 별칭 수는 허용되는 최대 인덱스 수의 두 배입니다.
| 리소스 | 무료 | Basic | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 최대 별칭 | 6 | 10 또는 30 | 100 | 400 | 400 | 파티션당 2000 또는 서비스당 6000 | 20 | 20 |
데이터 제한(AI 보강)
엔터티 인식, 엔터티 링크, 핵심 구 추출, 감정 분석, 언어 감지 및 개인 정보 검색에 대한 Azure AI Language 리소스로 호출을 만드는 AI 보강 파이프라인은 데이터가 제한될 수 있습니다. 레코드의 최대 크기는 String.Length에 의해 측정된 대로 50,000자여야 합니다. 감성 분석기로 보내기 전에 데이터를 분할해야 할 경우 텍스트 분할 기술을 사용합니다.
스로틀 제한
시스템이 최대 용량에 도달하면 API 요청이 제한됩니다. 제한은 API마다 다르게 동작합니다. 쿼리 API(검색/제안/자동 완성) 및 인덱싱 API는 서비스의 부하에 따라 동적으로 제한됩니다. 인덱스 API 및 서비스 작업 API에는 정적 요청률 제한이 있습니다.
인덱스와 관련된 작업에 대한 정적 요금 요청 제한:
- 인덱스 나열(GET /indexes): 검색 단위별 초당 3개
- 인덱스 가져오기(GET /indexes/myindex): 검색 단위별 초당 10개
- 인덱스 만들기(POST /indexes): 검색 단위별 분당 12개
- 인덱스 만들기 또는 업데이트(PUT /indexes/myindex): 검색 단위별 초당 6개
- 인덱스 삭제(DELETE /indexes/myindex): 검색 단위별 분당 12개
서비스와 관련된 작업에 대한 정적 속도 요청 제한:
- 서비스 통계(GET /servicestats): 검색 단위별 초당 4개
API 요청 제한
- 요청당 최대 16MB 1
- URL 길이 최대 8KB
- 인덱스 업로드, 병합 또는 삭제 일괄 처리당 최대 1,000개의 문서
- $orderby 절에 최대 32개의 필드
- 검색 절의 최대 100,000자
search의 최대 절 수(AND 또는 OR로 구분된 식)는 1024개입니다.- 최대 검색어 크기는 UTF-8 인코딩된 텍스트로 32,766바이트(32KB에서 2바이트를 뺀 값)입니다.
- 접두사 검색 및 정규식 검색의 최대 검색어 크기는 1,000자입니다.
- Lucene에서 처리할 때 와일드카드 검색 및 정규식 검색은 최대 1000개의 상태로 제한됩니다.
1 Azure AI 검색에서는 이론적 제한으로 달리 제한되지 않는 개별 필드 또는 컬렉션의 콘텐츠에 대한 실질적 한도를 부과하기 위해 요청 본문에 16MB의 상한이 적용됩니다(필드 컴퍼지션 및 제한 사항에 대한 자세한 내용은 지원되는 데이터 형식 참조).
바인딩되지 않은 쿼리는 검색 서비스를 불안정하게 만들 수 있으므로 쿼리 크기 및 컴퍼지션에 제한이 있습니다. 일반적으로 이러한 쿼리는 프로그래밍 방식으로 만들어집니다. 애플리케이션이 검색 쿼리를 프로그래밍 방식으로 생성하는 경우 쿼리가 제한 없는 크기로 생성되지 않도록 디자인하는 것이 좋습니다.
API 응답 제한
- 검색 결과 페이지당 반환되는 문서 최대 1,000개
- 제안 API 요청당 반환되는 제안 최대 100개
API 키 제한
API 키는 서비스 인증에 사용됩니다. 두 가지 형식이 있습니다. 관리자 키는 요청 헤더에서 지정되고 서비스에 전체 읽기/쓰기 액세스 권한을 부여합니다. 쿼리 키는 읽기 전용이며 URL에 지정되고 일반적으로 클라이언트 애플리케이션에 배포됩니다.
- 서비스당 최대 2개의 관리자 키
- 서비스당 최대 50개의 쿼리 키