Mengindeks blob dan file untuk menghasilkan beberapa dokumen pencarian

Berlaku untuk: Pengindeks Blob, Pengindeks file

Secara default, pengindeks memperlakukan konten blob atau file sebagai satu dokumen pencarian. Jika Anda menginginkan representasi yang lebih terperinci dalam indeks pencarian, Anda dapat mengatur nilai parsingMode untuk membuat beberapa dokumen pencarian dari satu blob atau file. Nilai parsingMode yang menghasilkan banyak dokumen penelusuran termasuk delimitedText (untuk CSV), dan jsonArray atau jsonLines (untuk JSON).

Saat Anda menggunakan salah satu mode penguraian ini, dokumen pencarian baru yang muncul harus memiliki kunci dokumen unik, dan masalah muncul dalam menentukan dari mana nilai itu berasal. Blob induk memiliki setidaknya satu nilai unik dalam bentuk metadata_storage_path property, tetapi jika itu menyumbangkan nilai tersebut ke lebih dari satu dokumen penelusuran, kuncinya tidak lagi unik dalam indeks.

Untuk mengatasi masalah ini, pengindeks blob menghasilkan AzureSearch_DocumentKey yang secara unik mengidentifikasi setiap dokumen penelusuran turunan yang dibuat dari induk blob tunggal. Artikel ini menjelaskan cara kerja fitur ini.

Kunci dokumen satu-ke-banyak

Setiap dokumen dalam indeks diidentifikasi secara unik oleh kunci dokumen. Ketika tidak ada mode penguraian yang ditentukan, dan jika tidak ada pemetaan bidang eksplisit dalam definisi pengindeks untuk kunci dokumen pencarian, pengindeks blob secara otomatis memetakan metadata_storage_path property sebagai kunci dokumen. Pemetaan default ini memastikan bahwa setiap blob muncul sebagai dokumen pencarian yang berbeda, dan ini menghemat langkah untuk membuat pemetaan bidang ini sendiri (biasanya, hanya bidang yang memiliki nama dan jenis yang identik yang dipetakan secara otomatis).

Dalam skenario dokumen pencarian satu-ke-banyak, kunci dokumen implisit berdasarkan metadata_storage_path property tidak dimungkinkan. Sebagai solusinya, Azure AI Search dapat menghasilkan kunci dokumen untuk setiap entitas individu yang diekstrak dari blob. Kunci yang dihasilkan diberi nama AzureSearch_DocumentKey dan ditambahkan ke setiap dokumen pencarian. Pengindeks melacak "banyak dokumen" yang dibuat dari setiap blob, dan dapat menargetkan pembaruan ke indeks pencarian saat data sumber berubah dari waktu ke waktu.

Secara default, ketika tidak ada pemetaan bidang eksplisit untuk bidang indeks kunci yang ditentukan, AzureSearch_DocumentKey dipetakan ke sana, menggunakan fungsi pemetaan bidang base64Encode.

Contoh

Asumsikan definisi indeks dengan bidang berikut:

• id
• temperature
• pressure
• timestamp

Dan kontainer blob Anda memiliki blob dengan struktur berikut:

Blob1.json

{ "temperature": 100, "pressure": 100, "timestamp": "2024-02-13T00:00:00Z" }
{ "temperature" : 33, "pressure" : 30, "timestamp": "2024-02-14T00:00:00Z" }

Blob2.json

{ "temperature": 1, "pressure": 1, "timestamp": "2023-01-12T00:00:00Z" }
{ "temperature" : 120, "pressure" : 3, "timestamp": "2022-05-11T00:00:00Z" }

Saat Anda membuat pengindeks dan mengatur parsingMode ke jsonLines - tanpa menentukan pemetaan bidang eksplisit untuk bidang kunci, pemetaan berikut diterapkan secara implisit.

{
    "sourceFieldName" : "AzureSearch_DocumentKey",
    "targetFieldName": "id",
    "mappingFunction": { "name" : "base64Encode" }
}

Penyiapan ini menghasilkan kunci dokumen yang tidak ambigu, mirip dengan ilustrasi berikut (ID yang dikodekan base64 dipersingkat untuk brevity).

Pemetaan bidang isian kustom untuk bidang kunci indeks

Dengan asumsi definisi indeks yang sama seperti contoh sebelumnya, misalkan kontainer blob Anda memiliki blob dengan struktur berikut:

Blob1.json

recordid, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z" 
2, 33, 30,"2024-02-14T00:00:00Z" 

Blob2.json

recordid, temperature, pressure, timestamp
1, 1, 1,"20123-01-12T00:00:00Z" 
2, 120, 3,"2022-05-11T00:00:00Z" 

Saat Anda membuat pengindeks dengan parsingModedelimitedText, mungkin terasa wajar untuk menyiapkan fungsi pemetaan bidang ke bidang kunci sebagai berikut:

{
    "sourceFieldName" : "recordid",
    "targetFieldName": "id"
}

Namun, pemetaan ini tidak mengakibatkan empat dokumen muncul dalam indeks karena recordid bidang tidak unik di seluruh blob. Oleh karena itu, kami menyarankan Anda untuk menggunakan pemetaan bidang implisit yang diterapkan dari properti AzureSearch_DocumentKey ke bidang indeks kunci untuk mode penguraian "satu-ke-banyak".

Jika Anda ingin menyiapkan pemetaan bidang eksplisit, pastikan sourceField berbeda untuk setiap entitas individu di semua blob.

Tentukan bidang kunci indeks di data Anda

Dengan asumsi definisi indeks yang sama dengan contoh sebelumnya dan parsingMode diatur ke jsonLines tanpa menentukan pemetaan bidang eksplisit sehingga pemetaan terlihat seperti dalam contoh pertama, misalkan kontainer blob Anda memiliki blob dengan struktur berikut:

Blob1.json

id, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z" 
2, 33, 30,"2024-02-14T00:00:00Z"

Blob2.json

id, temperature, pressure, timestamp
1, 1, 1,"2023-01-12T00:00:00Z" 
2, 120, 3,"2022-05-11T00:00:00Z" 

Perhatikan bahwa setiap dokumen berisi id bidang , yang didefinisikan sebagai key bidang dalam indeks. Dalam kasus seperti itu, meskipun unik AzureSearch_DocumentKey dokumen dihasilkan, itu tidak digunakan sebagai "kunci" untuk dokumen. Sebaliknya, nilai bidang dipetakan id ke key bidang

Mirip dengan contoh sebelumnya, pemetaan ini tidak menghasilkan empat dokumen yang muncul dalam indeks karena id bidang tidak unik di seluruh blob. Jika demikian, setiap entri json yang menentukan id hasil dalam penggabungan pada dokumen yang ada alih-alih unggahan dokumen baru, dan status indeks mencerminkan entri baca terbaru dengan yang ditentukan id.

Langkah berikutnya

Jika Anda belum terbiasa dengan struktur dasar dan alur kerja pengindeksan blob, Anda harus meninjau Pengindeksan Azure Blob Storage dengan Azure AI Search terlebih dahulu. Untuk informasi selengkapnya tentang mode penguraian untuk tipe konten blob yang berbeda, tinjau artikel berikut.