Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Catatan
Pencarian Azure AI tersedia melalui portal Azure, REST API, dan Azure SDK. Ini juga mendukung Foundry IQ, lapisan pengetahuan terkelola yang mengubah konten perusahaan menjadi pangkalan pengetahuan yang dapat digunakan kembali dan sadar izin untuk agen di portal Microsoft Foundry.
Pencarian Azure AI menawarkan dua model harga yang menangani kapasitas secara berbeda:
Khusus: Rencanakan kapasitas dengan mengukur replika dan partisi dan memilih tingkat layanan.
- Sediakan kapasitas secara langsung menggunakan replika dan partisi.
- Perkirakan penyimpanan yang diperlukan (partisi) dan kapasitas pemrosesan yang diperlukan (replika).
- Pilih tingkat layanan untuk menyediakan kapasitas yang diperlukan berdasarkan permintaan puncak yang diharapkan.
- Setelah mengonfigurasi kapasitas di muka, Anda membayar tarif per jam yang diukur oleh Unit Pencarian (SU), terlepas dari penggunaannya.
Tanpa server (Pratinjau): Layanan secara otomatis mengelola kapasitas berdasarkan batas penggunaan dan layanan. Anda tidak perlu menyediakan kapasitas terlebih dahulu. Sebagai gantinya, optimalkan efisiensi beban kerja Anda untuk mengelola biaya.
- Kapasitas secara otomatis diskalakan dengan permintaan (dapat menskalakan ke nol saat diam).
- Anda ditagih berdasarkan penggunaan aktual sebagaimana diukur oleh Unit Komputasi (CUs) dan penyimpanan.
- Daripada infrastruktur, perencanaan berfokus pada driver biaya ini: Pola kueri, Ukuran dan pertumbuhan indeks, dan Pola penyerapan data. Lihat Mengoptimalkan biaya untuk model Tanpa Server.
| Dimensi | Dedicated | Serverless |
|---|---|---|
| Model kapasitas | Tersedia (replika × partisi) | Berbasis konsumsi |
| Scaling | Manual | Otomatis |
| Kontrol pengguna | Eksplisit (konfigurasikan replika dan partisi) | Tidak langsung (dipengaruhi oleh karakteristik beban kerja) |
| Billing | Tarif per jam tetap per Unit Pencarian (SU) | Pembayaran berbasis konsumsi untuk Unit Komputasi (CUs) dan penyimpanan |
| biaya menganggur | Selalu dikenakan (kapasitas minimum yang diprovisikan) | Diskalakan ke nol saat tidak digunakan |
| Fokus pengoptimalan | Penentuan ukuran infrastruktur | Efisiensi beban kerja |
| Paling cocok untuk | Beban kerja yang dapat diprediksi dan stabil | Beban kerja yang variatif, dengan lonjakan, atau multi-penyewa, termasuk skenario yang digerakkan oleh agen |
| Pendekatan perencanaan kapasitas | Ukuran dan skala infrastruktur (replika dan partisi) | Mengoptimalkan efisiensi beban kerja dan pola penggunaan |
| Dampak inefisiensi | Latensi dan tantangan skalabilitas | Peningkatan biaya langsung |
Important
Tingkat Pengembang Tanpa Server saat ini dalam pratinjau. Pratinjau ini disediakan tanpa perjanjian tingkat layanan dan tidak direkomendasikan untuk beban kerja produksi. Fitur tertentu mungkin tidak didukung atau mungkin memiliki kemampuan terbatas. Untuk informasi lebih lanjut, lihat Supplemental Terms of Use for Microsoft Azure Previews.
Penagihan untuk tingkat Pengembang Tanpa Server dimulai pada 13 September 2026. Biaya untuk penggunaan pada atau setelah tanggal tersebut muncul pada tagihan Azure Anda. Anda tidak dikenakan biaya untuk penggunaan sebelum 13 September 2026. Pengembang Tanpa Server adalah tingkat berbayar setelah penagihan dimulai.
Tingkat Pengembang Tanpa Server tidak mendukung migrasi ke atau dari tingkat harga lain dan beberapa fitur yang tersedia di tingkat lain tidak didukung selama Pratinjau Umum. Batas layanan, fitur yang didukung, dan detail harga dapat berubah sebelum ketersediaan umum.
Pratinjau saat ini hanya tersedia di West Central US, Switzerland North, dan Japan East.
Untuk mempelajari lebih lanjut, lihat cara:
- Rencanakan dan kelola biaya
- Pilih model harga dan tingkat layanan
- Mengoptimalkan biaya dengan model harga Tanpa Server
Merencanakan kapasitas untuk model Khusus
Dalam model Khusus, Anda memprovisikan kapasitas dengan menggunakan Unit Pencarian (SU):
- Unit pencarian (SU) = replika × partisi
- Replika: Salinan mesin pencari. Menyediakan throughput kueri dan ketersediaan tinggi.
- Partisi: Unit penyimpanan. Menyediakan kapasitas pemrosesan untuk penyimpanan dan pengindeksan.
Setiap layanan dimulai dengan 1 replika × 1 partisi (1 SU). Anda dapat menambahkan atau menghapus replika dan partisi secara independen untuk mengakomodasi beban kerja yang berfluktuasi. Menambahkan kapasitas meningkatkan biaya menjalankan layanan pencarian.
| Konsep | Definisi |
|---|---|
| Unit pencarian | Satu kenaikan total kapasitas yang tersedia. Minimal satu unit pencarian diperlukan untuk menjalankan layanan. Tergantung pada tingkat harga Anda, rentang maksimum dari satu hingga 36 unit. Jumlah unit pencarian sama dengan jumlah replika yang dikalikan dengan jumlah partisi: R × P = SU. Setiap layanan dimulai dengan satu replika dan satu partisi, yang mengkonsumsi satu unit: 1 × 1 = 1. Menambahkan replika kedua menggunakan dua unit: 2 × 1 = 2. Unit pencarian juga merupakan unit penagihan untuk layanan pencarian. |
| Replika | Instans-instans layanan pencarian digunakan terutama untuk membalance beban operasi kueri. Setiap replika menyimpan satu salinan indeks. Jika Anda mengalokasikan tiga replika, Anda memiliki tiga salinan indeks yang tersedia untuk melayani permintaan kueri. |
| Partisi | Penyimpanan fisik dan I/O untuk operasi baca/tulis (misalnya, saat membangun kembali atau menyegarkan indeks). Setiap partisi memiliki bagian dari indeks keseluruhan. Jika Anda mengalokasikan tiga partisi, indeks Anda akan dibagi menjadi sepertiga. |
Tinjau tabel partisi dan replika untuk kemungkinan kombinasi yang tetap berada di bawah batas 36 unit.
Karakteristik fisik replika dan partisi, seperti kecepatan pemrosesan dan IO disk, bervariasi menurut tingkat layanan. Pada layanan pencarian standar, replika serta partisi berfungsi lebih cepat dan memiliki ukuran lebih besar dibandingkan dengan yang ada di layanan dasar.
Kapan harus menambahkan kapasitas untuk model Khusus
Pertimbangkan untuk menambahkan replika atau partisi saat:
- Peningkatan latensi kueri atau kriteria perjanjian tingkat layanan tidak terpenuhi.
- Frekuensi kesalahan HTTP 503 (Layanan tidak tersedia) meningkat.
- Frekuensi kesalahan HTTP 429 (Terlalu banyak permintaan) meningkat, menunjukkan pembatasan permintaan.
- Volume kueri besar diharapkan.
- Pekerjaan pengindeksan lambat atau tertinggal.
- Laju penyimpanan atau pengindeksan tidak memadai.
Panduan penskalaan:
- Tambahkan replika untuk meningkatkan kapasitas pemrosesan kueri dan ketersediaan.
- Tambahkan partisi untuk meningkatkan performa penyimpanan dan pengindeksan.
- Beban kerja dengan kueri tinggi biasanya memerlukan lebih banyak replika.
- Indeks besar mungkin memerlukan replika tambahan untuk mempertahankan performa.
Important
Operasi penskalakan dapat memakan waktu untuk menyelesaikan dan meningkatkan biaya. Selalu validasi perubahan dengan menggunakan pengujian performa dan perkiraan harga.
Tingkat layanan yang Anda pilih menentukan ukuran dan kecepatan partisi. Setiap tingkatan dioptimalkan di sekitar serangkaian karakteristik yang sesuai dengan berbagai skenario. Jika memilih tingkat kelas atas, Anda mungkin memerlukan lebih sedikit partisi daripada jika Anda menggunakan S1. Salah satu pertanyaan yang perlu Anda jawab melalui pengujian yang diarahkan sendiri adalah apakah partisi yang lebih besar dan lebih mahal menghasilkan performa yang lebih baik daripada dua partisi yang lebih murah pada layanan yang disediakan pada tingkat yang lebih rendah.
Satu layanan harus memiliki sumber daya yang memadai untuk menangani semua beban kerja (pengindeksan dan kueri). Tidak ada beban kerja yang berjalan di latar belakang. Anda dapat menjadwalkan pengindeksan untuk waktu ketika permintaan kueri secara alami lebih jarang, tetapi layanan tidak memprioritaskan satu tugas ke tugas lain. Selain itu, sejumlah redundansi akan memuluskan performa kueri ketika layanan atau simpul diperbarui secara internal.
Sebagai aturan umum, aplikasi pencarian cenderung membutuhkan lebih banyak replika daripada partisi, terutama ketika operasi layanan bias terhadap beban kerja kueri. Setiap replika adalah salinan indeks Anda, sehingga layanan dapat memuat permintaan keseimbangan terhadap beberapa salinan. Pencarian Azure AI mengelola semua penyeimbangan beban dan replikasi indeks. Anda dapat mengubah jumlah replika yang dialokasikan untuk layanan Anda kapan saja. Anda dapat mengalokasikan hingga 12 replika dalam layanan pencarian Standar dan 3 replika dalam layanan pencarian Dasar. Anda dapat membuat alokasi replika dari portal Azure atau salah satu opsi terprogram.
Partisi tambahan bermanfaat untuk pekerjaan pengindeksan yang intensif. Partisi tambahan menyebarkan operasi baca dan tulis di sejumlah besar sumber daya komputasi.
Terakhir, indeks yang lebih besar membutuhkan waktu lebih lama untuk kueri. Dengan demikian, Anda mungkin menemukan bahwa setiap peningkatan partisi secara bertahap membutuhkan peningkatan replika yang lebih kecil namun tetap proporsional. Kompleksitas kueri dan volume kueri Anda mempengaruhi seberapa cepat eksekusi kueri diselesaikan.
Untuk batas layanan dan rentang penskalaan yang valid, lihat:
Catatan
Menambahkan lebih banyak replika atau partisi akan meningkatkan biaya operasi layanan, dan dapat memunculkan sedikit variasi terkait bagaimana hasil dipesan. Pastikan untuk memeriksa kalkulator harga untuk memahami implikasi penagihan dari penambahan node. Tabel kombinasi partisi dan replika dapat membantu Anda mencocokkan jumlah unit pencarian yang diperlukan untuk konfigurasi tertentu. Untuk informasi selengkapnya tentang bagaimana replika tambahan memengaruhi pemrosesan kueri, lihat Mengurutkan hasil.
Cara mengelola dan menyesuaikan kapasitas
Mengubah kapasitas tidak seketika. Bergantung pada volume data dan jenis operasi, penskalakan dapat memakan waktu dari menit hingga beberapa jam.
Saat menskalakan layanan pencarian, Anda dapat memilih dari alat dan pendekatan berikut:
Catatan
Jika layanan pencarian Anda dibuat sebelum April atau Mei 2024, mungkin memenuhi syarat untuk peningkatan satu kali ke infrastruktur yang lebih baru dengan ukuran partisi yang lebih besar tanpa biaya tambahan. Peningkatan ini dapat meningkatkan penyimpanan yang tersedia per partisi dan mengurangi jumlah partisi yang diperlukan untuk beban kerja Anda. Untuk informasi selengkapnya, lihat Meningkatkan layanan pencarian Anda.
Untuk meningkatkan atau mengurangi kapasitas layanan, Anda memiliki dua opsi:
Menambahkan atau menghapus partisi dan replika
Buka layanan pencarian Anda di portal Azure.
Dari panel kiri, pilih Skala Pengaturan>.
Cuplikan layar berikut menunjukkan layanan Standar yang disediakan dengan satu replika dan satu partisi. Rumus di bagian bawah menunjukkan berapa banyak unit pencarian yang digunakan (1). Jika harga satuan adalah $100 (bukan harga riil), biaya bulanan untuk menjalankan layanan ini rata-rata akan menjadi $100.
Gunakan pengguncur untuk menambah atau mengurangi jumlah partisi, lalu pilih Simpan.
Contoh ini menambahkan replika dan partisi kedua. Perhatikan jumlah unit pencarian; sekarang menjadi empat karena rumus penagihan adalah jumlah replika dikalikan dengan jumlah partisi (2 x 2). Menggandakan kapasitas lebih dari itu akan menggandakan biaya operasi layanan. Jika biaya unit pencarian adalah $100, tagihan bulanan baru kini akan menjadi $400.
Untuk biaya per unit saat ini dari setiap tingkatan, kunjungi halaman harga.
Periksa pemberitahuan Anda untuk mengonfirmasi bahwa operasi dimulai.
Operasi ini dapat memakan waktu beberapa jam untuk diselesaikan. Ini terjadi di latar belakang, sehingga layanan pencarian Anda tetap beroperasi penuh dan tersedia untuk operasi baca dan tulis.
Anda tidak dapat membatalkan operasi atau memantau kemajuannya. Namun, pesan berikut ditampilkan saat perubahan sedang berlangsung.
Ubah tingkat harga Anda
Catatan
Portal Azure dan Services - Update (REST API) mendukung perubahan antara tingkat Dasar dan Standar (S1, S2, dan S3). Anda dapat meningkatkan atau menurunkan tingkatan, asalkan konfigurasi layanan Anda saat ini tidak melebihi batas tingkat target. Wilayah Anda juga tidak dapat memiliki batasan kapasitas pada tingkat target.
Tingkat harga Anda menentukan penyimpanan maksimum layanan pencarian Anda untuk model harga Khusus. Jika Anda membutuhkan lebih banyak atau kurang kapasitas, Anda dapat beralih ke tingkat harga berbeda yang mengakomodasi kebutuhan penyimpanan Anda. (Ini hanya berlaku untuk tingkat model harga Khusus. Tingkat Pengembang model tanpa server tidak dapat diubah setelah dipilih).
Selain kapasitas, tingkat harga menentukan batasan indeks, pengindeks, dan objek pencarian lainnya. Bandingkan batas layanan tingkat Anda saat ini dan tingkat yang Anda inginkan sebelum melanjutkan. Umumnya, beralih ke tingkat yang lebih tinggi meningkatkan batas penyimpanan dan batas vektor Anda, meningkatkan throughput permintaan, dan mengurangi latensi, sambil beralih ke tingkat yang lebih rendah memiliki efek yang berlawanan.
Beralih ke tingkat harga yang lebih tinggi juga meningkatkan biaya menjalankan layanan pencarian Anda. Untuk informasi lebih lanjut, lihat halaman harga.
Untuk mengubah tingkat harga Anda:
Buka layanan pencarian Anda di portal Azure.
Dari panel kiri, pilih Skala Pengaturan>.
Di bawah tingkat Anda saat ini, pilih Ubah Tingkat Harga.
Pada halaman Pilih Tingkat Harga , pilih tingkat yang berbeda dari daftar.
Anda dapat beralih antara Dasar, S1, S2, dan S3, tetapi Anda tidak dapat beralih ke atau dari Gratis, S3HD, L1, atau L2. Tingkatan ini tidak dapat dipilih dan tampak redup.
Untuk memulai operasi skala, pilih Simpan.
Operasi ini dapat memakan waktu beberapa jam untuk diselesaikan. Ini terjadi di latar belakang, sehingga layanan pencarian Anda tetap beroperasi penuh dan tersedia untuk operasi baca dan tulis.
Anda tidak dapat membatalkan operasi atau memantau kemajuannya. Namun, pesan berikut ditampilkan saat perubahan sedang berlangsung.
Bagaimana permintaan skala ditangani untuk model Khusus
Saat layanan pencarian menerima permintaan skala, layanan tersebut:
- Memeriksa apakah permintaan itu valid.
- Memulai pencadangan data dan informasi sistem.
- Memeriksa apakah layanan sudah dalam status penyediaan (sedang menambahkan atau menghilangkan replika atau partisi).
- Mulai proses penyediaan.
Meningkatkan skala layanan dapat memakan waktu beberapa menit hingga beberapa jam, tergantung pada ukuran layanan dan cakupan permintaan. Durasi pencadangan juga bervariasi berdasarkan jumlah data dan jumlah partisi dan replika.
Langkah-langkah untuk menangani permintaan skala tidak sepenuhnya berturut-turut. Misalnya, sistem memulai penyediaan ketika dapat melakukannya dengan aman, yang bisa terjadi saat proses pencadangan hampir selesai.
Kesalahan selama penskalaan
Tabel berikut ini mencantumkan penyebab dan solusi untuk kesalahan yang dapat terjadi selama operasi penskalaan.
| Pesan kesalahan | Penyebab | Solusi |
|---|---|---|
| "Operasi pembaruan layanan saat ini tidak diizinkan karena kami memproses permintaan sebelumnya." | Operasi penskalakan lain sedang berlangsung. | Periksa halaman Overview di portal Azure atau gunakan rest API Search Management, Azure PowerShell, atau Azure CLI untuk mendapatkan status layanan pencarian Anda. Jika statusnya adalah "Provisi," tunggu hingga menjadi "Berhasil" atau "Gagal" sebelum Anda mencoba lagi. 1, 2 |
| "Gagal menskalakan nama layanan pencarian. Kesalahan: Jumlah objekActualCount melebihi batas yang diizinkan: MaximumCount." | Konfigurasi layanan Anda saat ini melebihi batas tingkat harga target. | Periksa apakah penggunaan penyimpanan, penggunaan vektor, indeks, pengindeks, dan objek lainnya sesuai dengan batas layanan tingkat bawah. Misalnya, tingkat Dasar mendukung hingga 15 indeks, sehingga Anda tidak dapat beralih dari S1 ke Dasar jika Anda memiliki 16 indeks. Sesuaikan sumber daya Anda sebelum mencoba lagi. |
1 Tidak ada status untuk pencadangan, yang merupakan operasi internal dan kecil kemungkinan mengganggu proses penskalaan.
2 Jika layanan pencarian Anda tampaknya terhenti dalam status provisi, periksa indeks yatim piatu yang tidak dapat digunakan, yang memiliki volume kueri nol dan tidak ada pembaruan indeks. Indeks yang tidak dapat digunakan dapat memblokir perubahan pada kapasitas layanan. Secara khusus, cari indeks terenkripsi CMK yang kuncinya tidak lagi valid. Hapus indeks atau pulihkan kunci untuk membuat indeks kembali online dan buka blokir operasi penskalakan Anda.
Kombinasi partisi dan replika
Bagan berikut berlaku untuk tingkat Standar dan yang lebih tinggi. Ini menunjukkan semua kemungkinan kombinasi partisi dan replika, dengan batas maksimum 36 unit pencarian untuk setiap layanan.
| 1 partisi | 2 partisi | 3 partisi | 4 partisi | 6 partisi | 12 partisi | |
|---|---|---|---|---|---|---|
| 1 replika | 1 SU | 2 SU | 3 SU | 4 SU | 6 SU | 12 SU |
| 2 replika | 2 SU | 4 SU | 6 SU | 8 SU | 12 SU | 24 SU |
| 3 replika | 3 SU | 6 SU | 9 SU | 12 SU | 18 SU | 36 SU |
| 4 replika | 4 SU | 8 SU | 12 SU | 16 SU | 24 SU | Tidak Berlaku |
| 5 buah replika | 5 SU | 10 SU | 15 SU | 20 SU | 30 SU | Tidak Berlaku |
| 6 replika | 6 SU | 12 SU | 18 SU | 24 SU | 36 SU | Tidak Berlaku |
| 12 replika | 12 SU | 24 SU | 36 SU | Tidak Berlaku | Tidak Berlaku | Tidak Berlaku |
Layanan pencarian dasar memiliki jumlah unit pencarian yang lebih rendah.
Pada layanan pencarian yang dibuat sebelum 3 April 2024, layanan dasar dapat memiliki tepat satu partisi dan hingga tiga replika dengan batas maksimum tiga SU. Satu-satunya sumber daya yang dapat disesuaikan adalah replika. Namun, Anda mungkin dapat meningkatkan jumlah partisi dengan meningkatkan layanan Anda.
Pada layanan pencarian yang dibuat setelah 3 April 2024 di wilayah yang didukung, layanan Dasar dapat memiliki hingga tiga partisi dan tiga replika. Batas maksimum SU adalah sembilan untuk mendukung konfigurasi lengkap partisi dan replika.
Untuk layanan pencarian pada setiap tingkat berbayar, terlepas dari tanggal pembuatan, Anda memerlukan minimal dua replika untuk ketersediaan tinggi dalam melakukan kueri.
Untuk tarif penagihan per tingkat dan mata uang, lihat halaman harga Pencarian Azure AI.
Perkirakan kapasitas menggunakan tingkat model harga Khusus
Kebutuhan penyimpanan Anda bergantung pada ukuran indeks yang ingin Anda bangun. Tidak ada heuristik yang solid atau pedoman umum yang membantu perkiraan. Satu-satunya cara untuk menentukan ukuran indeks adalah dengan membangunnya. Ukurannya tergantung pada tokenisasi dan penyematan, dan apakah Anda mengaktifkan pemberi saran, pemfilteran, dan pengurutan, atau dapat memanfaatkan kompresi vektor.
Perkirakan kapasitas pada tingkat berbayar Basic atau yang lebih tinggi. Tingkat Gratis berjalan pada sumber daya fisik yang dibagikan oleh beberapa pelanggan dan tunduk pada faktor-faktor di luar kendali Anda. Hanya sumber daya khusus dari layanan pencarian yang dapat ditagih yang dapat mengakomodasi waktu pengambilan sampel dan pemrosesan yang lebih besar untuk perkiraan jumlah, ukuran, dan volume kueri indeks yang lebih realistis selama pengembangan.
Tinjau batas layanan di setiap tingkatan untuk menentukan apakah tingkatan yang lebih rendah dapat mendukung jumlah indeks yang Anda butuhkan. Pertimbangkan apakah Anda memerlukan beberapa salinan indeks untuk pengembangan, pengujian, dan produksi aktif.
Layanan pencarian tunduk pada batas objek (jumlah maksimum indeks, pengindeks, set keterampilan, dan sebagainya) dan batas penyimpanan. Batas mana pun yang tercapai terlebih dahulu adalah batas efektif.
Membuat layanan pada tingkat berbayar. Tingkatan dioptimalkan untuk beban kerja tertentu. Misalnya, tingkat Storage Optimized memiliki batas 10 indeks karena dirancang untuk mendukung jumlah indeks besar yang rendah.
Mulailah dari level yang rendah, pada level Dasar atau S1, jika Anda ragu tentang beban proyeksi.
Mulai dari tinggi, pada S2 atau bahkan S3, jika pengujian mencakup beban pengindeksan dan kueri berskala besar.
Mulailah dengan Optimasi Penyimpanan pada L1 atau L2, jika Anda mengindeks sejumlah besar data dan beban kueri relatif rendah, seperti halnya dengan aplikasi bisnis internal.
Buat indeks awal untuk menentukan bagaimana data sumber diterjemahkan ke indeks. Ini adalah satu-satunya cara untuk memperkirakan ukuran indeks. Atribut pada definisi bidang memengaruhi persyaratan penyimpanan fisik:
Untuk pencarian kata kunci, menandai bidang sebagai dapat difilter dan dapat diurutkan meningkatkan ukuran indeks.
Untuk pencarian vektor, Anda dapat mengatur parameter untuk mengurangi ukuran vektor.
Pantau penyimpanan, batas layanan, volume kueri, dan latensi di portal Azure. portal Azure menampilkan kueri per detik, kueri yang dibatasi lajunya, dan latensi pencarian. Nilai-nilai ini dapat membantu Anda memutuskan apakah Anda memilih tingkat yang tepat.
Tambahkan replika untuk ketersediaan tinggi atau untuk mengurangi performa kueri yang lambat.
Tidak ada pedoman tentang berapa banyak replika yang diperlukan untuk mengakomodasi beban kueri. Performa kueri bergantung pada kompleksitas kueri dan beban kerja yang bersaing. Meskipun menambahkan replika dengan jelas menghasilkan performa yang lebih baik, hasilnya tidak linier secara ketat: menambahkan tiga replika tidak menjamin throughput tiga kali lipat. Untuk panduan dalam memperkirakan QPS untuk solusi Anda, lihat Menganalisis performa dan Memantau kueri.
Untuk indeks terbalik, ukuran, dan kompleksitas ditentukan oleh konten, tidak harus dengan jumlah data yang Anda umpankan ke dalamnya. Sumber data besar dengan redundansi tinggi dapat menghasilkan indeks yang lebih kecil daripada himpunan data yang lebih kecil yang berisi konten yang sangat bervariasi. Jadi, hampir tidak mungkin untuk menyimpulkan ukuran indeks berdasarkan ukuran himpunan data asli.
Persyaratan penyimpanan dapat dilambungkan jika Anda menyertakan data yang tidak pernah Anda cari. Idealnya, dokumen hanya berisi data yang Anda butuhkan untuk pengalaman pencarian.
Pertimbangan perjanjian tingkat layanan
Perjanjian tingkat layanan (SLA) tidak mencakup fitur tingkat gratis dan pratinjau. Untuk semua tingkatan yang dapat ditagih, SLA berlaku ketika Anda memprovisikan redundansi yang cukup untuk layanan Anda.
Dua atau lebih replika memenuhi SLA untuk kueri (membaca).
Tiga replika atau lebih memenuhi SLA kueri dan pengindeksan (baca-tulis).
Jumlah partisi tidak memengaruhi SLA.
Mengoptimalkan biaya untuk model Tanpa Server
Dalam model harga Tanpa Server:
- Layanan secara otomatis mengelola kapasitas.
- Anda tidak perlu mengonfigurasi replika, partisi, atau unit pencarian.
- Sumber daya komputasi dapat diskalakan secara dinamis berdasarkan beban kerja (kebutuhan kueri dan pengindeksan) dan dapat diskalakan hingga nol saat tidak digunakan.
Untuk mempelajari selengkapnya tentang batasan untuk model Tanpa Server, lihat Batas layanan.
Penagihan didasarkan pada dua dimensi:
- Penggunaan komputasi (CUs): Dikenakan biaya berdasarkan operasi kueri dan pengindeksan.
- Penyimpanan terindeks: Dikenakan biaya per GB per bulan.
Karena penagihan berbasis konsumsi, biaya langsung terkait dengan penggunaan:
- Kueri kompleks mengonsumsi lebih banyak komputasi.
- Desain skema yang tidak efisien meningkatkan biaya pengindeksan dan kueri.
- Pola kueri yang buruk dengan indeks besar atau yang sering diperbarui meningkatkan penyimpanan dan penggunaan komputasi.
Mengoptimalkan efisiensi beban kerja
Karena inefisiensi muncul sebagai biaya dalam model Tanpa Server, Anda membayar lebih untuk pekerjaan yang sama jika Anda tidak mempraktikkan desain sadar beban kerja. Cara terbaik untuk mengontrol pengeluaran Tanpa Server adalah dengan merancang indeks dan kueri Anda secara efisien sejak awal.
Untuk merancang beban kerja demi efisiensi saat menggunakan model harga Tanpa Server, pertimbangkan:
Desain indeks
- Sertakan hanya bidang yang digunakan dalam kueri.
- Kurangi dimensi vektor jika memungkinkan.
- Hindari atribut yang dapat difilter, diurutkan, atau dapat difaset yang tidak perlu.
Pola kueri
- Gunakan
$selectuntuk membatasi bidang yang dikembalikan. - Terapkan filter lebih awal untuk mengurangi kumpulan hasil.
- Hindari paging mendalam (
$skip). - Lebih suka kueri yang ditargetkan daripada kueri teks lengkap yang luas.
- Gunakan pencarian hibrid dengan hati-hati karena biaya komputasi yang lebih tinggi.
Monitoring
- Pantau konsumsi CU untuk mengidentifikasi kueri yang mahal.
- Lacak pertumbuhan penyimpanan dan hapus data yang tidak digunakan.
Di Tanpa Server, meningkatkan performa (kueri yang lebih cepat dan lebih ditargetkan) biasanya mengurangi biaya.
Untuk mempelajari selengkapnya, lihat Optimisasi biaya dengan model harga Tanpa Server di Pencarian Azure AI.
Pertimbangan kapasitas regional
Kapasitas dan ketersediaan dapat bervariasi menurut wilayah yang didukung. Beberapa wilayah mungkin memiliki batasan dalam menyediakan layanan baru atau menskalakan yang sudah ada.
Catatan
Selama pratinjau publik, model harga Tanpa Server hanya tersedia di sekumpulan wilayah terbatas. Lihat pemberitahuan pratinjau di awal artikel ini.
Jika wilayah Pencarian Azure AI pilihan Anda tidak tersedia karena kendala kapasitas, lihat Cara menangani batasan kapasitas regional di Pencarian Azure AI.