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 jsonArrayjsonLines (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 propertydokumentu, 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 delimitedTextparsingMode 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 idkó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.