Mengindeks himpunan data besar di Azure AI Search

  • Artikel

Jika persyaratan solusi pencarian Anda mencakup pengindeksan big data atau data kompleks, artikel ini mengartikulasikan strategi untuk mengakomodasi proses jangka panjang di Azure AI Search.

Artikel ini mengasumsikan keakraban dengan dua pendekatan dasar untuk mengimpor data: mendorong data ke dalam indeks, atau menarik data dari sumber data yang didukung menggunakan pengindeks pencarian. Jika skenario Anda melibatkan pengayaan AI intensif komputasi, maka pengindeks diperlukan, mengingat dependensi skillset pada pengindeks.

Artikel ini melengkapi Tips untuk performa yang lebih baik, yang menawarkan praktik terbaik tentang desain indeks dan kueri. Indeks yang dirancang dengan baik yang hanya mencakup bidang dan atribut yang Anda butuhkan adalah prasyarat penting untuk pengindeksan skala besar.

Sebaiknya gunakan layanan pencarian yang lebih baru, dibuat setelah 3 April 2024, untuk penyimpanan yang lebih tinggi per partisi.

Catatan

Strategi yang dijelaskan dalam artikel ini mengasumsikan satu sumber data besar. Jika solusi Anda memerlukan pengindeksan dari beberapa sumber data, lihat Mengindeks beberapa sumber data di Azure AI Search untuk pendekatan yang direkomendasikan.

Mengindeks data besar menggunakan API pendorongan

API "Dorong", seperti Dokumen Indeks REST API atau metode IndexDocuments (Azure SDK untuk .NET), adalah bentuk pengindeksan yang paling umum di Azure AI Search. Untuk solusi yang menggunakan API pendorongan, strategi untuk pengindeksan jangka panjang akan memiliki satu atau kedua komponen berikut:

  • Dokumen batching
  • Mengelola utas

Batch beberapa dokumen per permintaan

Mekanisme sederhana untuk mengindeks data dalam jumlah besar adalah mengirimkan beberapa dokumen atau rekaman dalam satu permintaan. Selama seluruh payload di bawah 16 MB, permintaan dapat menangani hingga 1000 dokumen dalam operasi pengunggahan massal. Batas ini berlaku baik Anda menggunakan Rest API Indeks Dokumen atau metode IndexDocuments di .NET SDK. Untuk salah satu API, Anda akan mengemas 1000 dokumen dalam isi setiap permintaan.

Dokumen batching akan secara signifikan mempersingkat jumlah waktu yang diperlukan untuk bekerja melalui volume data yang besar. Menentukan ukuran batch optimal untuk data Anda adalah komponen kunci untuk mengoptimalkan kecepatan pengindeksan. Dua faktor utama yang memengaruhi ukuran batch yang optimal adalah:

  • Skema indeks Anda
  • Ukuran data Anda

Karena ukuran batch optimal tergantung pada indeks dan data Anda, pendekatan terbaik adalah menguji ukuran batch yang berbeda untuk menentukan mana yang menghasilkan kecepatan pengindeksan tercepat untuk skenario Anda. Tutorial: Optimalkan pengindeksan dengan API push menyediakan kode sampel untuk menguji ukuran batch menggunakan .NET SDK.

Menambahkan utas dan strategi coba lagi

Pengindeks memiliki manajemen utas bawaan, tetapi saat Anda menggunakan API pendorongan, kode aplikasi Anda harus mengelola utas. Pastikan ada utas yang cukup untuk memanfaatkan kapasitas yang tersedia secara penuh, terutama jika Anda baru saja meningkatkan partisi atau telah meningkatkan ke layanan pencarian tingkat yang lebih tinggi.

  1. Tingkatkan jumlah utas bersamaan dalam kode klien Anda.

  2. Saat Anda meningkatkan permintaan yang mencapai layanan pencarian, Anda mungkin menemukan kode status HTTP yang menunjukkan permintaan tidak sepenuhnya berhasil. Selama pengindeksan, dua kode status HTTP umum adalah:

    • 503 Layanan Tidak Tersedia - Kesalahan ini berarti bahwa sistem berada pada kondisi beban berat, dan permintaan Anda tidak dapat diproses saat ini.

    • 207 Multi-Status - Kesalahan ini berarti bahwa beberapa dokumen berhasil, tetapi minimal satu dokumen gagal.

  3. Untuk menangani kegagalan, permintaan harus dicoba kembali menggunakan strategi coba lagi backoff eksponensial.

Azure .NET SDK secara otomatis mencoba kembali 503s dan permintaan lain yang gagal, tetapi Anda harus menerapkan logika Anda sendiri untuk mencoba kembali 207s. Alat sumber terbuka seperti Polly juga dapat digunakan untuk menerapkan strategi coba ulang.

Indeks dengan pengindeks dan API "pull"

Pengindeks memiliki beberapa kemampuan yang berguna untuk proses jangka panjang:

  • Dokumen batching
  • Pengindeksan paralel atas data yang dipartisi
  • Menjadwalkan dan mengubah deteksi untuk mengindeks hanya baru dan mengubah dokumen dari waktu ke waktu

Jadwal pengindeks dapat melanjutkan pemrosesan pada titik pemberhentian terakhir yang diketahui. Jika data tidak sepenuhnya diindeks dalam jendela pemrosesan, pengindeks mengambil di mana pun yang ditinggalkannya pada eksekusi berikutnya, dengan asumsi Anda menggunakan sumber data yang menyediakan deteksi perubahan.

Saat menggunakan pengindeks, mempartisi data ke sumber data individual yang lebih kecil memungkinkan pemrosesan paralel. Anda dapat memecah data sumber, seperti menjadi beberapa kontainer di Azure Blob Storage, membuat sumber data untuk setiap partisi, lalu menjalankan pengindeks secara paralel, tunduk pada jumlah unit pencarian layanan pencarian Anda.

Periksa ukuran batch pengindeks

Seperti halnya API pendorongan, pengindeks memungkinkan Anda untuk mengonfigurasi jumlah item per batch. Untuk pengindeks berdasarkan pada Membuat REST API Pengindeks, Anda dapat mengaturbatchSize argumen untuk menyesuaikan pengaturan ini agar lebih sesuai dengan karakteristik data Anda.

Ukuran batch default berukuran spesifik sumber data. Azure SQL Database dan Azure Cosmos DB memiliki ukuran batch default 1000. Sebaliknya, pengindeksan Azure Blob menetapkan ukuran batch pada 10 dokumen sebagai pengakuan atas ukuran dokumen rata-rata yang lebih besar.

Menjadwalkan pengindeks untuk proses yang berjalan lama

Penjadwalan pengindeks adalah mekanisme penting untuk memproses himpunan data besar dan untuk mengakomodasi proses yang berjalan lambat seperti analisis gambar dalam alur pengayaan.

Biasanya, pemrosesan pengindeks berjalan dalam jendela 2 jam. Jika beban kerja pengindeksan membutuhkan waktu berjam-hari daripada jam untuk diselesaikan, Anda dapat menempatkan pengindeks pada jadwal berulang berturut-turut yang dimulai setiap dua jam. Dengan asumsi sumber data mengaktifkan pelacakan perubahan, pengindeks akan melanjutkan pemrosesan di tempat terakhir kali ditinggalkan. Pada irama ini, pengindeks dapat bekerja melalui backlog dokumen selama serangkaian hari sampai semua dokumen yang tidak diproses diproses.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Ketika tidak ada lagi dokumen baru atau yang diperbarui di sumber data, riwayat eksekusi pengindeks akan melaporkan 0/0 dokumen yang diproses, dan tidak ada pemrosesan yang terjadi.

Untuk informasi selengkapnya tentang pengaturan jadwal, lihat Membuat INDEXer REST API atau lihat Cara menjadwalkan pengindeks untuk Azure AI Search.

Catatan

Beberapa pengindeks yang berjalan pada arsitektur runtime yang lebih lama memiliki jendela pemrosesan maksimum 24 jam daripada 2 jam. Batas 2 jam adalah untuk prosesor konten yang lebih baru yang berjalan di lingkungan multi-penyewa yang dikelola secara internal. Jika memungkinkan, Azure AI Search mencoba membongkar pengindeks dan pemrosesan skillset ke lingkungan multi-penyewa. Jika pengindeks tidak dapat dimigrasikan, pengindeks akan berjalan di lingkungan privat dan dapat berjalan selama 24 jam. Jika Anda menjadwalkan pengindeks yang menunjukkan karakteristik ini, asumsikan jendela pemrosesan 24 jam.

Menjalankan pengindeks secara paralel

Jika Anda mempartisi data, Anda dapat membuat beberapa kombinasi sumber data pengindeks yang menarik dari setiap sumber data dan menulis ke indeks pencarian yang sama. Karena setiap pengindeks berbeda, Anda dapat menjalankannya pada saat yang sama, mengisi indeks pencarian lebih cepat daripada jika Anda menjalankannya secara berurutan.

Pastikan Anda memiliki kapasitas yang memadai. Satu unit pencarian di layanan Anda dapat menjalankan satu pengindeks pada waktu tertentu. Membuat beberapa pengindeks hanya berguna jika dapat berjalan secara paralel.

Jumlah pekerjaan pengindeksan yang dapat berjalan secara bersamaan bervariasi untuk pengindeksan berbasis teks dan berbasis keterampilan. Untuk informasi selengkapnya, lihat Eksekusi pengindeks.

Jika sumber data Anda adalah kontainer Azure Blob Storage atau Azure Data Lake Storage Gen 2, menghitung sejumlah besar blob dapat memakan waktu lama (bahkan berjam-jam) hingga operasi ini selesai. Ini akan menyebabkan bahwa jumlah dokumen pengindeks Anda berhasil tidak ditingkatkan selama waktu itu dan tampaknya tidak membuat kemajuan apa pun, ketika itu terjadi. Jika Anda ingin pemrosesan dokumen berjalan lebih cepat untuk sejumlah besar blob, pertimbangkan untuk mempartisi data Anda ke dalam beberapa kontainer dan membuat pengindeks paralel yang menunjuk ke satu indeks.

  1. Masuk ke portal Azure dan periksa jumlah unit pencarian yang digunakan oleh layanan pencarian Anda. Pilih Pengaturan> Scale untuk melihat nomor di bagian atas halaman. Jumlah pengindeks yang akan berjalan secara paralel kira-kira sama dengan jumlah unit pencarian.

  2. Mempartisi data sumber di antara beberapa kontainer atau beberapa folder virtual di dalam kontainer yang sama.

  3. Buat beberapa sumber data, satu untuk setiap partisi, dipasangkan ke pengindeksnya sendiri.

  4. Tentukan indeks pencarian target yang sama di setiap pengindeks.

  5. Jadwalkan pengindeks.

  6. Tinjau status pengindeks dan riwayat eksekusi untuk konfirmasi.

Ada beberapa risiko yang terkait dengan pengindeksan paralel. Pertama, ingat bahwa pengindeksan tidak berjalan di latar belakang, meningkatkan kemungkinan kueri akan dibatasi atau dihilangkan.

Kedua, Azure AI Search tidak mengunci indeks untuk pembaruan. Penulisan bersamaan dikelola, memanggil coba lagi jika penulisan tertentu tidak berhasil pada upaya pertama, tetapi Anda mungkin melihat peningkatan kegagalan pengindeksan.

Meskipun beberapa set sumber data pengindeks dapat menargetkan indeks yang sama, berhati-hatilah terhadap pengindeks berjalan yang dapat menimpa nilai yang ada dalam indeks. Jika sumber data pengindeks kedua menargetkan dokumen dan bidang yang sama, nilai apa pun dari eksekusi pertama akan ditimpa. Nilai bidang diganti secara penuh; pengindeks tidak dapat menggabungkan nilai dari beberapa eksekusi ke bidang yang sama.

Mengindeks big data di Spark

Jika Anda memiliki arsitektur big data dan data Anda ada di kluster Spark, kami sarankan SynapseML untuk memuat dan mengindeks data. Tutorial ini mencakup langkah-langkah untuk memanggil layanan Azure AI untuk pengayaan AI, tetapi Anda juga dapat menggunakan API AzureSearchWriter untuk pengindeksan teks.

Lihat juga