Batas layanan di Azure AI Search
Batas maksimum penyimpanan, beban kerja, dan jumlah indeks dan objek lainnya bergantung pada apakah Anda membuat Azure AI Search di tingkat harga Gratis, Dasar, Standar, atau Penyimpanan yang Dioptimalkan.
Gratis adalah layanan bersama multipenyewa yang disertakan dengan langganan Azure Anda.
Dasar menyediakan sumber daya komputasi khusus untuk beban kerja produksi dalam skala yang lebih kecil, tetapi berbagi beberapa infrastruktur jaringan dengan penyewa lain.
Standar berjalan pada komputer khusus dengan lebih banyak kapasitas penyimpanan dan pemrosesan di setiap level. Standar hadir dalam empat level: S1, S2, S3, dan S3 HD. S3 High Density (S3 HD) direkayasa untuk multi-penyewaan dan sejumlah besar indeks kecil (3.000 indeks per layanan). S3 HD tidak menyediakan fitur pengindeks dan penyerapan data harus menggunakan API yang mendorong data dari sumber ke indeks.
Penyimpanan Yang Dioptimalkan berjalan pada komputer khusus dengan lebih banyak penyimpanan total, bandwidth penyimpanan, dan memori daripada Standar. Tingkat ini menargetkan indeks besar yang berubah-lambat. Penyimpanan yang Dioptimalkan hadir dalam dua level: L1 dan L2.
Batas langganan
Anda dapat membuat beberapa layanan pencarian yang dapat ditagih (Dasar dan lebih tinggi), hingga jumlah maksimum layanan yang diizinkan di setiap tingkatan, per wilayah. Misalnya, Anda dapat membuat hingga 16 layanan di tingkat Dasar dan 16 layanan lain di tingkat S1 dalam langganan dan wilayah yang sama. Anda kemudian dapat membuat 16 layanan Dasar tambahan di wilayah lain untuk total gabungan 32 layanan Dasar di bawah langganan yang sama. Untuk informasi selengkapnya tentang tingkatan, lihat Memilih tingkat (atau SKU) untuk Pencarian Azure AI.
Batas layanan maksimum dapat dinaikkan berdasarkan permintaan. Jika Anda memerlukan lebih banyak layanan dalam langganan yang sama, ajukan permintaan dukungan.
Sumber daya | Gratis 1 | Dasar | S1 | S2 | S3 | S3 HD | L1 | L2 |
---|---|---|---|---|---|---|---|---|
Layanan maksimum per wilayah | 1 | 16 | 16 | 8 | 6 | 6 | 6 | 6 |
Unit pencarian maksimum (SU)2 | T/A | 3 SU | 36 SU | 36 SU | 36 SU | 36 SU | 36 SU | 36 SU |
1 Anda dapat memiliki satu layanan pencarian gratis per langganan Azure. Tingkat gratis didasarkan pada infrastruktur yang dibagikan dengan pelanggan lain. Karena perangkat keras tidak didedikasikan, peningkatan skala tidak didukung, dan penyimpanan dibatasi hingga 50 MB. Layanan pencarian gratis mungkin dihapus setelah jangka waktu tidak aktif yang lama untuk memberikan ruang bagi lebih banyak layanan.
2 Unit pencarian (SU) adalah unit penagihan, dialokasikan sebagai replika atau partisi. Kau butuh keduanya. Untuk mempelajari selengkapnya tentang kombinasi SU, lihat Memperkirakan dan mengelola kapasitas layanan pencarian.
Batas layanan
Tabel berikut mencakup jumlah SLA, partisi, dan replika di tingkat layanan.
Sumber daya | Gratis | Dasar | S1 | S2 | S3 | S3 HD | L1 | L2 |
---|---|---|---|---|---|---|---|---|
Perjanjian tingkat layanan (SLA) | Tidak | Ya | Ya | Ya | Ya | Ya | Ya | Ya |
Partitions | T/A | 3 1 | 12 | 12 | 12 | 3 | 12 | 12 |
Replika | T/A | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
1 Tingkat dasar mendukung tiga partisi dan tiga replika, untuk total sembilan unit pencarian (SU) pada layanan pencarian baru yang dibuat setelah 3 April 2024. Layanan dasar yang lebih lama terbatas pada satu partisi dan tiga replika.
Layanan pencarian tunduk pada batas penyimpanan maksimum (ukuran partisi dikalikan dengan jumlah partisi) atau dengan batas keras pada jumlah maksimum indeks atau pengindeks, mana yang lebih dulu.
Perjanjian tingkat layanan (SLA) berlaku untuk layanan yang dapat ditagih yang memiliki dua atau beberapa replika untuk beban kerja kueri, atau tiga replika atau lebih untuk beban kerja kueri dan pengindeksan. Jumlah partisi bukanlah pertimbangan SLA. Untuk informasi selengkapnya, lihat Keandalan di Pencarian Azure AI.
Layanan gratis tidak memiliki partisi atau replika tetap dan mereka berbagi sumber daya dengan pelanggan lain.
Penyimpanan partisi (GB)
Batas penyimpanan per layanan bervariasi menurut dua hal: tanggal pembuatan layanan, dan wilayah. Ada batas yang lebih tinggi untuk layanan yang lebih baru di sebagian besar wilayah yang didukung.
Tabel ini menunjukkan perkembangan peningkatan kuota penyimpanan dalam GB dari waktu ke waktu. Partisi kapasitas yang lebih tinggi dibawa secara online mulai April 2024, di wilayah yang tercantum dalam catatan kaki. Kapasitas yang lebih tinggi terbatas pada layanan pencarian baru. Saat ini tidak ada peningkatan di tempat.
Tanggal pembuatan layanan | Dasar | S1 | S2 | S3/HD | L1 | L2 |
---|---|---|---|---|---|---|
Sebelum 3 April 2024 | 2 | 25 | 100 | 200 | 1,024 | 2.048 |
April 3, 2024 hingga Mei 17, 2024 1 | 15 | 160 | 512 | 1,024 | 1,024 | 2.048 |
Setelah 17 Mei 2024 2 | 15 | 160 | 512 | 1,024 | 2,048 | 4,096 |
1 Penyimpanan kapasitas yang lebih tinggi untuk Dasar, S1, S2, S3 di wilayah ini. Amerika: Brasil Selatan, Kanada Tengah, Kanada Timur, AS Timur, US Timur 2, AS Tengah, US Tengah Utara, AS Tengah Selatan, AS Barat, AS Barat 2, AS Barat 3, AS Tengah Barat. Eropa: Prancis Tengah. Italia Utara, Eropa Utara, Norwegia Timur, Polandia Tengah, Swiss Utara, Swedia Tengah, UK Selatan, Inggris Barat. Timur Tengah: UEA Utara. Afrika: Afrika Selatan Utara. Asia Pasifik: Australia Timur, Australia Tenggara, India Tengah, Jio India Barat, Asia Timur, Asia Tenggara, Jepang Timur, Jepang Barat, Korea Tengah, Korea Selatan.
2 Penyimpanan kapasitas yang lebih tinggi untuk L1 dan L2. Lebih banyak wilayah memberikan kapasitas yang lebih tinggi di setiap tingkat yang dapat ditagih. Eropa: Jerman Utara, Jerman Barat Tengah, Swiss Barat. Azure Government: Texas, Arizona, Virginia. Afrika: Afrika Selatan Utara. Asia Pasifik: Tiongkok Utara 3, Tiongkok Timur 3.
Beberapa wilayah masih berjalan pada infrastruktur yang lebih lama, tunduk pada batas 3 April. Sebelum membuat layanan baru, periksa wilayah yang didukung untuk memastikan wilayah pilihan Anda menyediakan kapasitas tambahan.
Batas indeks
Sumber daya | Gratis | Dasar 1 | S1 | S2 | S3 | S3 HD | L1 | L2 |
---|---|---|---|---|---|---|---|---|
Indeks maksimum | 3 | 5 atau 15 | 50 | 200 | 200 | 1000 per partisi atau 3000 per layanan | 10 | 10 |
Bidang sederhana maksimum per indeks 2 | 1000 | 100 | 1000 | 1000 | 1000 | 1000 | 1000 | 1000 |
Dimensi maksimum per bidang vektor | 4098 | 4098 | 4098 | 4098 | 4098 | 4098 | 4098 | 4098 |
Koleksi kompleks maksimum per indeks | 40 | 40 | 40 | 40 | 40 | 40 | 40 | 40 |
Elemen maksimum di semua koleksi kompleks per dokumen 3 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 | 3000 |
Kedalaman maksimum bidang kompleks | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
Pemberi saran maksimum per indeks | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
Profil penilaian maksimum per indeks | 100 | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
Fungsi maksimum per profil | 8 | 8 | 8 | 8 | 8 | 8 | 8 | 8 |
Ukuran indeks maksimum 4 | T/A | T/A | T/A | 1,88 TB | 2,34 TB | 100 GB | T/A | T/A |
1 Layanan dasar yang dibuat sebelum Desember 2017 memiliki batas bawah (5, bukan 15) pada indeks. Tingkat dasar adalah satu-satunya tingkat dengan batas bawah 100 bidang per indeks.
2 Batas atas bidang mencakup bidang tingkat pertama dan subbidang berlapis dalam koleksi yang kompleks. Misalnya, jika indeks berisi 15 bidang dan memiliki dua koleksi kompleks dengan masing-masing lima subbidang, jumlah bidang indeks Anda adalah 25. Indeks dengan koleksi bidang yang sangat besar bisa lambat. Batasi bidang dan atribut hanya untuk yang Anda butuhkan, dan jalankan pengujian pengindeksan dan kueri untuk memastikan performa dapat diterima.
3 Batas atas ada untuk elemen karena memiliki sejumlah besar dari mereka secara signifikan meningkatkan penyimpanan yang diperlukan untuk indeks Anda. Elemen koleksi kompleks didefinisikan sebagai anggota koleksi tersebut. Misalnya, asumsikan dokumen Hotel dengan koleksi kompleks Kamar, setiap kamar dalam koleksi Kamar dianggap sebagai elemen. Selama pengindeksan, mesin pengindeksan dapat dengan aman memproses maksimum 3.000 elemen di seluruh dokumen secara keseluruhan.
Batas ini dimasukkan padaapi-version=2019-05-06
dan berlaku hanya untuk koleksi kompleks, dan tidak untuk koleksi string atau bidang kompleks.
4 Pada sebagian besar tingkatan, ukuran indeks maksimum adalah semua penyimpanan yang tersedia di layanan pencarian Anda. Untuk S2, S3, dan S3 HD, ukuran maksimum indeks apa pun adalah angka yang disediakan dalam tabel. Berlaku untuk layanan pencarian yang dibuat setelah 3 April 2024.
Anda mungkin menemukan beberapa variasi dalam batas maksimum jika layanan Anda kebetulan disediakan pada kluster yang lebih kuat. Batasan di sini mewakili penyedenominator umum. Indeks yang dibangun berdasarkan spesifikasi di atas portabel di seluruh tingkat layanan yang setara di wilayah mana pun.
Batas dokumen
Jumlah maksimum dokumen per indeks adalah:
- 24 miliar pada Basic, S1, S2, S3
- 2 miliar pada S3 HD
- 288 miliar pada L1
- 576 miliar pada L2
Ukuran maksimum setiap dokumen adalah sekitar 16 megabyte. Ukuran dokumen sebenarnya adalah batas ukuran payload permintaan API pengindeksan, yaitu 16 megabyte. Payload tersebut dapat berupa satu dokumen, atau batch dokumen. Untuk batch dengan satu dokumen, ukuran dokumen maksimum adalah 16 MB JSON.
Ukuran dokumen berlaku untuk pengindeksan mode dorong yang mengunggah dokumen ke layanan pencarian. Jika Anda menggunakan pengindeks untuk pengindeksan mode tarik, file sumber Anda dapat menjadi ukuran file apa pun, yang tunduk pada batas pengindeks. Untuk pengindeks blob, batas ukuran file lebih besar untuk tingkat yang lebih tinggi. Misalnya, batas S1 adalah 128 megabyte, batas S2 adalah 256 megabyte, dan sebagainya.
Saat memperkirakan ukuran dokumen, ingatlah untuk mengindeks hanya bidang yang menambahkan nilai ke skenario pencarian Anda, dan kecualikan bidang sumber apa pun yang tidak memiliki tujuan dalam kueri yang ingin Anda jalankan.
Batas ukuran indeks vektor
Saat Anda mengindeks dokumen dengan bidang vektor, Azure AI Search membuat indeks vektor internal menggunakan parameter algoritma yang Anda berikan. Ukuran indeks vektor ini dibatasi oleh memori yang dicadangkan untuk pencarian vektor untuk tingkat layanan Anda (atau SKU
). Untuk panduan tentang mengelola dan memaksimalkan penyimpanan vektor, lihat Ukuran indeks vektor dan tetap di bawah batas.
Batas vektor bervariasi menurut:
Batas vektor yang lebih tinggi mulai April 2024 dan seterusnya ada pada layanan pencarian baru di wilayah yang menyediakan kapasitas tambahan, yang sebagian besar dari mereka.
Tabel ini menunjukkan perkembangan peningkatan kuota vektor dalam GB dari waktu ke waktu. Kuota per partisi, jadi jika Anda menskalakan layanan Standar (S1) baru menjadi 6 partisi, total kuota vektor adalah 35 dikalikan dengan 6.
Tanggal pembuatan layanan | Dasar | S1 | S2 | S3/HD | L1 | L2 |
---|---|---|---|---|---|---|
Sebelum 1 Juli 20231 | 0,5 | 1 | 6 | 12 | 12 | 36 |
Juli 1, 2023 hingga April 3, 20242 | 1 | 3 | 12 | 36 | 12 | 36 |
April 3, 2024 hingga Mei 17, 20243 | 5 | 35 | 150 | 300 | 12 | 36 |
Setelah 17 Mei 20244 | 5 | 35 | 150 | 300 | 150 | 300 |
1 Batas vektor awal selama pratinjau awal.
2 Batas vektor selama periode pratinjau selanjutnya. Tiga wilayah tidak memiliki batas yang lebih tinggi: Jerman Barat Tengah, India Barat, Qatar Tengah.
3 Kuota vektor yang lebih tinggi berdasarkan partisi yang lebih besar untuk tingkat dan wilayah yang didukung.
4 Kuota vektor yang lebih tinggi untuk lebih banyak tingkatan dan wilayah berdasarkan pembaruan ukuran partisi.
Layanan ini memberlakukan kuota ukuran indeks vektor untuk setiap partisi di layanan pencarian Anda. Setiap partisi tambahan meningkatkan kuota ukuran indeks vektor yang tersedia. Kuota ini adalah batas yang sulit untuk memastikan layanan Anda tetap sehat, yang berarti bahwa upaya pengindeksan lebih lanjut setelah batas terlampaui menghasilkan kegagalan. Anda dapat melanjutkan pengindeksan setelah mengosongkan kuota yang tersedia dengan menghapus beberapa dokumen vektor atau dengan meningkatkan skala dalam partisi.
Penting
Batas vektor yang lebih tinggi terkait dengan ukuran partisi yang lebih besar. Wilayah yang berjalan pada infrastruktur yang lebih lama tunduk pada batas Juli-April. Tinjau daftar wilayah untuk status pada batas penyimpanan partisi.
Batas pengindeks
Waktu berjalan maksimum ada untuk memberikan keseimbangan dan stabilitas pada layanan secara keseluruhan, tetapi kumpulan data yang lebih besar mungkin memerlukan lebih banyak waktu pengindeksan daripada waktu maksimum yang diizinkan. Jika pekerjaan pengindeksan tidak dapat diselesaikan dalam waktu maksimum yang diizinkan, coba jalankan sesuai jadwal. Penjadwal melacak status pengindeksan. Jika pekerjaan pengindeksan terjadwal terganggu karena alasan apa pun, pengindeks dapat melanjutkan di tempat terakhir yang ditinggalkannya saat menjalankan jadwal berikutnya.
Sumber daya | Gratis 1 | Dasar 2 | S1 | S2 | S3 | S3 HD 3 | L1 | L2 |
---|---|---|---|---|---|---|---|---|
Pengindeks maksimum | 3 | 5 atau 15 | 50 | 200 | 200 | T/A | 10 | 10 |
Sumber data maksimum | 3 | 5 atau 15 | 50 | 200 | 200 | T/A | 10 | 10 |
Skillset maksimum 4 | 3 | 5 atau 15 | 50 | 200 | 200 | T/A | 10 | 10 |
Beban pengindeksan maksimum per invokasi | 10.000 dokumen | Hanya dibatasi oleh dokumen maksimum | Hanya dibatasi oleh dokumen maksimum | Hanya dibatasi oleh dokumen maksimum | Hanya dibatasi oleh dokumen maksimum | T/A | Tidak ada batasan | Tidak ada batasan |
Jadwal minimum | 5 menit | 5 menit | 5 menit | 5 menit | 5 menit | 5 menit | 5 menit | 5 menit |
Waktu berjalan maksimum 5 | 1-3 atau 3-10 menit | 2 atau 24 jam | 2 atau 24 jam | 2 atau 24 jam | 2 atau 24 jam | T/A | 2 atau 24 jam | 2 atau 24 jam |
Pengindeks blob: ukuran blob maksimum, MB | 16 | 16 | 128 | 256 | 256 | T/A | 256 | 256 |
Pengindeks blob: karakter maksimum konten yang diekstrak dari blob 6 | 32.000 | 64.000 | 4 juta | 8 juta | 16 juta | T/A | 4 juta | 4 juta |
1 Layanan gratis memiliki waktu eksekusi maksimum pengindeks 3 menit untuk sumber blob, dan 1 menit untuk semua sumber data lainnya. Pemanggilan pengindeks adalah setiap 180 detik sekali. Untuk pengindeksan AI yang memanggil ke layanan Azure AI, layanan gratis dibatasi hingga 20 transaksi gratis per pengindeks per hari, di mana transaksi didefinisikan sebagai dokumen yang berhasil melewati alur pengayaan (tip: Anda dapat mengatur ulang pengindeks untuk mengatur ulang jumlahnya).
2 Layanan dasar yang dibuat sebelum Desember 2017 memiliki batas bawah (5, bukan 15) pada indeks.
3 Layanan HD S3 tidak menyertakan dukungan pengindeks.
4 Maksimum 30 keterampilan per skillset.
5 Mengenai durasi maksimum 2 atau 24 jam untuk pengindeks: maksimum 2 jam adalah yang paling umum dan itulah yang harus Anda rencanakan. Ini mengacu pada pengindeks yang berjalan di lingkungan publik, digunakan untuk membongkar pemrosesan intensif komputasi dan meninggalkan lebih banyak sumber daya untuk kueri. Batas 24 jam berlaku jika Anda mengonfigurasi pengindeks untuk berjalan di lingkungan privat hanya menggunakan infrastruktur yang dialokasikan untuk layanan pencarian Anda. Perhatikan bahwa beberapa pengindeks yang lebih lama tidak dapat berjalan di lingkungan publik, dan pengindeks tersebut selalu memiliki rentang pemrosesan 24 jam. Jika Anda memiliki pengindeks yang tidak terjadwal yang berjalan terus menerus selama 24 jam, Anda dapat mengasumsikan pengindeks tersebut tidak dapat dimigrasikan ke infrastruktur yang lebih baru. Sebagai aturan umum, untuk pekerjaan pengindeksan yang tidak dapat diselesaikan dalam waktu dua jam, letakkan pengindeks pada jadwal 5 menit sehingga pengindeks dapat dengan cepat mengambil tempat yang ditinggalkannya. Pada tingkat Gratis, waktu berjalan maksimum 3-10 menit adalah untuk pengindeks dengan set keterampilan.
6 Jumlah maksimum karakter didasarkan pada unit kode Unicode, khususnya UTF-16.
Catatan
Seperti yang dinyatakan dalam batas Indeks, pengindeks juga akan memberlakukan batas atas 3000 elemen di semua koleksi kompleks per dokumen yang dimulai dengan versi GA API terbaru yang mendukung jenis kompleks (2019-05-06
) dan seterusnya. Ini berarti bahwa jika Anda telah membuat pengindeks dengan versi API sebelumnya, Anda tidak akan tunduk pada batas ini. Untuk mempertahankan kompatibilitas maksimum, pengindeks yang dibuat dengan versi API sebelumnya lalu diperbarui dengan versi API 2019-05-06
atau yang lebih baru, akan tetap dikecualikan dari batas. Pelanggan harus menyadari dampak buruk dari memiliki koleksi kompleks yang sangat besar (seperti yang dinyatakan sebelumnya) dan kami sangat menyarankan untuk membuat pengindeks baru dengan versi GA API terbaru.
Batas sumber daya tautan privat bersama
Pengindeks dapat mengakses sumber daya Azure lainnya melalui titik akhir privat yang dikelola melalui API sumber daya tautan privat bersama. Bagian ini menjelaskan batasan yang terkait dengan kemampuan ini.
Sumber daya | Gratis | Dasar | S1 | S2 | S3 | S3 HD | L1 | L2 |
---|---|---|---|---|---|---|---|---|
Dukungan pengindeks titik akhir privat | Tidak | Ya | Ya | Ya | Ya | No | Ya | Ya |
Dukungan titik akhir privat untuk pengindeks dengan skillset1 | Tidak | No | No | Ya | Ya | No | Ya | Ya |
Dukungan titik akhir privat untuk pengindeks dengan set keterampilan dan vektorisasi terintegrasi 2 | Tidak | Ya | Ya | Ya | Ya | No | Ya | Ya |
Titik akhir privat maksimum | T/A | 10 atau 30 | 100 | 400 | 400 | T/A | 20 | 20 |
Jenissumber daya maksimum yang berbeda 3 | T/A | 4 | 7 | 15 | 15 | T/A | 4 | 4 |
1 Pengayaan AI dan analisis gambar secara komputasi intensif dan mengonsumsi jumlah daya pemrosesan yang tersedia secara tidak proporsional. Untuk alasan ini, koneksi privat dinonaktifkan pada tingkat yang lebih rendah untuk memastikan performa dan stabilitas layanan pencarian itu sendiri.
2 Layanan berkapasitas tinggi yang dibuat setelah 3 April 2024 di wilayah yang tercantum di bawah Partition Storage dan menjalankan beban kerja vektorisasi terintegrasi pada waktu pengindeksan mendukung tautan privat bersama dalam tingkat berbayar. Sistem harus mendeteksi setidaknya keterampilan yang menyematkan data.
3 Jumlah jenis sumber daya yang berbeda dihitung sebagai jumlah nilai unik groupId
yang digunakan di semua sumber daya tautan privat bersama untuk layanan pencarian tertentu, terlepas dari status sumber daya.
Batas sinonim
Jumlah maksimum peta sinonim bervariasi menurut tingkatan. Setiap aturan dapat memiliki hingga 20 ekspansi, di mana ekspansi adalah istilah yang setara. Misalnya, diberikan "kucing", asosiasi dengan "kucing", "feline", dan "felis" (genus untuk kucing) akan dihitung sebagai 3 ekspansi.
Sumber daya | Gratis | Dasar | S1 | S2 | S3 | S3-HD | L1 | L2 |
---|---|---|---|---|---|---|---|---|
Peta sinonim maksimum | 3 | 3 | 5 | 10 | 20 | 20 | 10 | 10 |
Jumlah maksimum aturan per peta | 5000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 | 20000 |
Batas alias indeks
Jumlah maksimum alias indeks bervariasi menurut tingkat dan tanggal pembuatan layanan. Di semua tingkatan, jika layanan dibuat setelah Oktober 2022, jumlah maksimum alias adalah dua kali lipat dari jumlah maksimum indeks yang diizinkan. Jika layanan dibuat sebelum Oktober 2022, batasnya adalah jumlah indeks yang diizinkan.
Tanggal Pembuatan Layanan | Gratis | Dasar | S1 | S2 | S3 | S3-HD | L1 | L2 |
---|---|---|---|---|---|---|---|---|
Sebelum Oktober 2022 | 3 | 5 atau 15 1 | 50 | 200 | 200 | 1000 per partisi atau 3000 per layanan | 10 | 10 |
Setelah Oktober 2022 | 6 | 30 | 100 | 400 | 400 | 2000 per partisi atau 6000 per layanan | 20 | 20 |
1 Layanan dasar yang dibuat sebelum Desember 2017 memiliki batas yang lebih rendah (5, bukan 15) pada indeks
Batas data (pengayaan AI)
Alur pengayaan AI yang melakukan panggilan ke sumber daya Bahasa Azure AI untuk pengenalan entitas, penautan entitas, ekstraksi frasa kunci, analisis sentimen, deteksi bahasa, dan deteksi informasi pribadi tunduk pada batas data. Ukuran maksimum rekaman harus 50.000 karakter sebagaimana diukur oleh String.Length
. Jika Anda perlu memecah data Anda sebelum mengirimkannya ke penganalisis sentimen, gunakan keahlian Pemisahan Teks.
Batas Pembatasan
Permintaan API dibatasi saat sistem mendekati kapasitas puncak. Pembatasan berperilaku berbeda untuk API yang berbeda. API Kueri (Search/Suggest/Autocomplete) dan pembatasan API pengindeksan secara dinamis berdasarkan beban pada layanan. API indeks dan API operasi layanan memiliki batas tingkat permintaan statik.
Batas permintaan laju statik untuk operasi yang terkait dengan indeks:
- Daftar Indeks (GET /indexes): 3 per detik per unit pencarian
- Dapatkan Indeks (GET /indexes/myindex): 10 per detik per unit pencarian
- Buat Indeks (POST /indexes): 12 per menit per unit pencarian
- Buat atau Perbarui Indeks (PUT /indexes/myindex): 6 per detik per unit pencarian
- Indeks Hapus (DELETE /indexes/myindex): 12 per menit per unit pencarian
Batas permintaan laju statik untuk operasi yang terkait dengan indeks:
- Statistik Layanan (GET /servicestats): 4 per detik per unit pencarian
Batas pembatasan ranker semantik
Peringkat semantik menggunakan sistem antrean untuk mengelola permintaan bersamaan. Sistem ini memungkinkan layanan pencarian mendapatkan jumlah kueri tertinggi per detik yang mungkin. Ketika batas permintaan bersamaan tercapai, permintaan tambahan ditempatkan dalam antrean. Jika antrean penuh, permintaan lebih lanjut akan ditolak dan harus dicoba kembali.
Total kueri pemeringkat semantik per detik bervariasi berdasarkan faktor-faktor berikut:
- Tingkat layanan pencarian. Kapasitas antrean dan batas permintaan bersamaan bervariasi menurut tingkatan.
- Jumlah unit pencarian di layanan pencarian. Cara paling sederhana untuk meningkatkan jumlah maksimum kueri peringkat semantik bersamaan adalah dengan menambahkan lebih banyak unit pencarian ke layanan pencarian Anda.
- Total kapasitas pemeringkat semantik yang tersedia di wilayah tersebut.
- Jumlah waktu yang diperlukan untuk melayani kueri menggunakan ranker semantik. Ini bervariasi berdasarkan seberapa sibuk layanan pencarian.
Tabel berikut ini menjelaskan batas pembatasan ranker semantik berdasarkan tingkatan, tunduk pada kapasitas yang tersedia di wilayah tersebut. Anda dapat menghubungi dukungan Microsoft untuk meminta peningkatan batas.
Sumber daya | Dasar | S1 | S2 | S3 | S3-HD | L1 | L2 |
---|---|---|---|---|---|---|---|
Permintaan Bersamaan Maksimum (per Unit Pencarian) | 2 | 3 | 4 | 4 | 4 | 4 | 4 |
Ukuran Antrean Permintaan Maksimum (per Unit Pencarian) | 4 | 6 | 8 | 8 | 8 | 8 | 8 |
Batas permintaan API
Batasan kueri ada karena kueri yang tidak terikat dapat mendestabilisasi layanan pencarian Anda. Biasanya, kueri tersebut dibuat secara terprogram. Jika aplikasi Anda menghasilkan kueri pencarian secara terprogram, sebaiknya merancangnya sedemikian sehingga tidak menghasilkan kueri dengan ukuran yang tidak terbatas.
Batasan payload ada karena alasan serupa, memastikan stabilitas layanan pencarian Anda. Batas berlaku untuk seluruh permintaan, termasuk semua komponennya. Misalnya, jika permintaan mengumpulkan beberapa dokumen atau perintah, seluruh permintaan harus sesuai dengan batas yang didukung.
Jika Anda harus melebihi batas yang didukung, Anda harus menguji beban kerja sehingga Anda tahu apa yang diharapkan.
Kecuali jika dicatat, permintaan API berikut berlaku untuk semua antarmuka yang dapat diprogram, termasuk Azure SDK.
Umum:
- Batas payload maksimum yang didukung adalah 16 MB untuk pengindeksan dan permintaan kueri melalui REST API dan SDK.
- Panjang URL maksimum 8 KB (hanya berlaku untuk REST API).
API pengindeksan:
- Mendukung maksimum 1.000 dokumen per batch unggahan indeks, penggabungan, atau penghapusan.
API Kueri:
- Maksimum 32 bidang dalam klausa $orderby.
- Maksimum 100.000 karakter dalam klausa pencarian.
- Jumlah maksimum klausa dalam pencarian adalah 3.000.
- Batas maksimum pada kueri wildcard dan ekspresi reguler, seperti yang diberlakukan oleh Lucene. Ini membatasi jumlah pola, variasi, atau kecocokan hingga 1.000 instans. Batas ini diberlakukan untuk menghindari kelebihan beban mesin.
Istilah pencarian:
- Ukuran istilah pencarian maksimum yang didukung adalah 32.766 byte (32 KB dikurangi 2 byte) teks yang dikodekan UTF-8. Berlaku untuk pencarian kata kunci dan properti teks pencarian vektor.
- Ukuran istilah pencarian maksimum yang didukung adalah 1.000 karakter untuk pencarian awalan dan pencarian regex.
Batas respons API
- Maksimum 1.000 dokumen yang dikembalikan per halaman hasil pencarian
- Maksimum 100 saran yang dikembalikan per permintaan Sarankan API
Mesin pencari mengembalikan 50 hasil secara default, tetapi Anda dapat mengambil alih parameter ini hingga batas maksimum.
Batas kunci API
Kunci API digunakan untuk autentikasi layanan. Ada dua jenis. Kunci admin ditentukan di header permintaan dan memberikan akses baca-tulis secara penuh ke layanan. Kunci kueri bersifat hanya-baca, ditentukan pada URL, dan biasanya didistribusikan ke aplikasi klien.
- Maksimum 2 kunci admin per layanan
- Maksimum 50 kunci kueri per layanan