Indexování objektů blob a souborů za účelem vytvoření více vyhledávacích dokumentů
Platí pro: Indexery objektů blob, indexery souborů
Indexer ve výchozím nastavení zachází s obsahem objektu blob nebo souboru jako s jedním prohledávacím dokumentem. Pokud chcete podrobnější reprezentaci v indexu vyhledávání, můžete nastavit hodnoty parsingMode pro vytvoření více vyhledávacích dokumentů z jednoho objektu blob nebo souboru. Hodnoty parsingMode , které vedou k mnoha dokumentům hledání, zahrnují delimitedText
(pro CSV) nebo jsonArray
jsonLines
(pro JSON).
Když použijete některý z těchto režimů analýzy, nové dokumenty hledání, které se objeví, musí mít jedinečné klíče dokumentu a vzniká problém při určování, odkud tato hodnota pochází. Nadřazený objekt blob má alespoň jednu jedinečnou hodnotu ve formě , ale pokud přispívá k této hodnotě do více než jednoho vyhledávacího metadata_storage_path property
dokumentu, klíč už není jedinečný v indexu.
Aby se tento problém vyřešil, indexer objektů blob vygeneruje AzureSearch_DocumentKey
jedinečný identifikátor každého podřízeného vyhledávacího dokumentu vytvořeného z nadřazeného objektu blob. Tento článek vysvětluje, jak tato funkce funguje.
Klíč dokumentu 1:N
Každý dokument v indexu je jednoznačně identifikován klíčem dokumentu. Pokud není zadán žádný režim analýzy a neexistuje žádné explicitní mapování polí v definici indexeru pro klíč dokumentu vyhledávání, indexer objektů blob automaticky mapuje metadata_storage_path property
jako klíč dokumentu. Toto výchozí mapování zajišťuje, aby se každý objekt blob zobrazoval jako samostatný vyhledávací dokument a uložil vám krok vytvoření mapování tohoto pole sami (obvykle se automaticky mapují jenom pole s identickými názvy a typy).
Ve scénáři 1:N prohledat dokument není možné implicitní klíč dokumentu založený na metadata_storage_path property
tom. Jako alternativní řešení může Azure AI Search vygenerovat klíč dokumentu pro každou jednotlivou entitu extrahovanou z objektu blob. Vygenerovaný klíč je pojmenovaný AzureSearch_DocumentKey
a přidá se do každého hledaného dokumentu. Indexer sleduje "mnoho dokumentů" vytvořených z každého objektu blob a může cílit na aktualizace indexu vyhledávání, když se zdrojová data v průběhu času změní.
Pokud není zadáno žádné explicitní mapování polí pro pole indexu klíče, AzureSearch_DocumentKey
mapuje se na něj pomocí base64Encode
funkce mapování polí.
Příklad
Předpokládejme definici indexu s následujícími poli:
id
temperature
pressure
timestamp
Kontejner objektů blob má objekty blob s následující strukturou:
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" }
Když vytvoříte indexer a nastavíte parsingMode na jsonLines
– bez zadání explicitních mapování polí pro pole klíče, následující mapování se použije implicitně.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Výsledkem tohoto nastavení jsou nejednoznačné klíče dokumentu, podobně jako na následujícím obrázku (ID kódování base64 se zkracuje kvůli stručnosti).
ID | Teplota | tlak | časové razítko |
---|---|---|---|
aHR0 ... YjEuanNvbjsx | 100 | 100 | 2024-02-13T00:00:00Z |
aHR0 ... YjEuanNvbjsy | 33 | 30 | 2024-02-14T00:00:00Z |
aHR0 ... YjIuanNvbjsx | 1 | 1 | 2023-01-12T00:00:00Z |
aHR0 ... YjIuanNvbjsy | 120 | 3 | 2022-05-11T00:00:00Z |
Mapování vlastních polí pro pole klíče indexu
Předpokládejme, že kontejner objektů blob má stejnou definici indexu jako v předchozím příkladu s následující strukturou:
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"
Při vytváření indexeru s delimitedText
parsingMode může být přirozené nastavit funkci mapování polí na klíčové pole následujícím způsobem:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Toto mapování ale nebude mít za následek zobrazení čtyř dokumentů v indexu, protože recordid
pole není jedinečné napříč objekty blob. Proto doporučujeme použít implicitní mapování polí použité z AzureSearch_DocumentKey
vlastnosti na pole indexu klíče pro režimy analýzy 1:N.
Pokud chcete nastavit explicitní mapování polí, ujistěte se, že je pole sourceField jedinečné pro každou jednotlivou entitu napříč všemi objekty blob.
Poznámka:
Přístup používaný zajištěním AzureSearch_DocumentKey
jedinečnosti u extrahované entity se může změnit, a proto byste se neměli spoléhat na její hodnotu pro potřeby vaší aplikace.
Zadání pole indexového klíče v datech
Za předpokladu, že je stejná definice indexu jako v předchozím příkladu a parsingMode je nastavená na jsonLines
bez zadání explicitních mapování polí, aby mapování vypadala jako v prvním příkladu, předpokládejme, že kontejner objektů blob má objekty blob s následující strukturou:
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"
Všimněte si, že každý dokument obsahuje id
pole, které je definováno jako key
pole v indexu. V takovém případě, i když se vygeneruje jedinečný AzureSearch_DocumentKey
dokument, nebude se pro dokument používat jako klíč. Místo toho se hodnota id
pole namapuje na key
pole.
Podobně jako v předchozím příkladu toto mapování nebude mít za následek zobrazení čtyř dokumentů v indexu, protože id
pole není jedinečné napříč objekty blob. V takovém případě každá položka JSON, která určuje id
, bude výsledkem sloučení existujícího dokumentu místo nahrání nového dokumentu a stav indexu bude odrážet nejnovější položku čtení se zadaným id
kódem .
Další kroky
Pokud ještě neznáte základní strukturu a pracovní postup indexování objektů blob, měli byste nejprve zkontrolovat indexování služby Azure Blob Storage pomocí služby Azure AI Search . Další informace o parsování režimů pro různé typy obsahu objektů blob najdete v následujících článcích.