Blobok és fájlok indexelése több keresési dokumentum létrehozásához

A következőkre vonatkozik: Blobindexerek, Fájlindexelők

Az indexelők alapértelmezés szerint egyetlen keresési dokumentumként kezelik egy blob vagy fájl tartalmát. Ha részletesebb megjelenítést szeretne egy keresési indexben, beállíthatja az parsingMode értékeket, hogy több keresési dokumentumot hozzon létre egy blobból vagy fájlból. A sok keresési dokumentumot eredményező parsingMode értékek közé tartoznak delimitedText a (CSV) és jsonArrayjsonLines a (JSON esetén).

Ezen elemzési módok bármelyikének használatakor a megjelenő új keresési dokumentumoknak egyedi dokumentumkulcsokkal kell rendelkezniük, és probléma merül fel annak meghatározásában, hogy az érték honnan származik. A szülőblob legalább egy egyedi értékkel metadata_storage_path propertyrendelkezik, de ha több keresési dokumentumhoz is hozzájárul, a kulcs már nem egyedi az indexben.

A probléma megoldásához a blobindexelő létrehoz egy AzureSearch_DocumentKey olyan fájlt, amely egyedileg azonosítja az egyetlen blob szülője által létrehozott gyermekkeresési dokumentumokat. Ez a cikk a funkció működését ismerteti.

Egy-a-többhöz dokumentumkulcs

Az indexben lévő összes dokumentumot egyedileg azonosítja egy dokumentumkulcs. Ha nincs megadva elemzési mód, és nincs explicit mezőleképezés a keresési dokumentumkulcs indexelődefiníciójában, a blobindexelő automatikusan dokumentumkulcsként leképezi azt metadata_storage_path property . Ez az alapértelmezett leképezés biztosítja, hogy az egyes blobok különálló keresési dokumentumként jelenjenek meg, és menti a mezőleképezés létrehozásának lépését (általában csak az azonos nevű és típusú mezők vannak automatikusan leképezve).

Egy-a-többhöz keresési dokumentum forgatókönyvében nem lehet implicit dokumentumkulcsot használni metadata_storage_path property . Áthidaló megoldásként az Azure AI Search létrehozhat egy dokumentumkulcsot a blobból kinyert minden egyes entitáshoz. A létrehozott kulcs neve el van nevezve AzureSearch_DocumentKey , és minden keresési dokumentumhoz hozzá lesz adva. Az indexelő nyomon követi az egyes blobokból létrehozott "sok dokumentumot", és a forrásadatok időbeli változásakor megcélozza a keresési index frissítéseit.

Alapértelmezés szerint ha nincs megadva explicit mezőleképezés a kulcsindex mezőhöz, a rendszer a AzureSearch_DocumentKey mezőleképezési függvény használatával leképezi azt base64Encode .

Példa

Tegyük fel, hogy egy indexdefiníció a következő mezőkkel rendelkezik:

• id
• temperature
• pressure
• timestamp

A blobtárolóban pedig a következő struktúrájú blobok vannak:

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" }

Amikor létrehoz egy indexelőt, és beállítja az elemzésIMode értékét – anélkül, hogy jsonLines explicit mezőleképezéseket ad meg a kulcsmezőhöz, a következő leképezés implicit módon lesz alkalmazva.

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

Ez a beállítás az alábbi ábrához hasonló egyértelmű dokumentumkulcsokat eredményez (a rövidítéshez rövidített base64 kódolású azonosító).

Egyéni mezőleképezés indexkulcsmezőhöz

Tegyük fel, hogy a blobtároló az előző példával megegyező indexdefinícióval rendelkezik, és az alábbi struktúrával rendelkezik:

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" 

Amikor létrehoz egy indexelőt delimitedTextaz parsingMode használatával, természetesnek tűnhet, ha egy mezőleképezési függvényt állít be a kulcsmezőre az alábbiak szerint:

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

Ez a leképezés azonban nem eredményez négy dokumentum megjelenítését az indexben, mert a recordid mező nem egyedi a blobok között. Ezért javasoljuk, hogy használja a tulajdonságból az AzureSearch_DocumentKey "egy-a-többhöz" elemzési módok kulcsindexmezőjére alkalmazott implicit mezőleképezést.

Ha explicit mezőleképezést szeretne beállítani, győződjön meg arról, hogy a sourceField minden egyes entitáshoz különböző az összes blobban.

Az indexkulcs mezőjének megadása az adatokban

Feltételezve, hogy az előző példával megegyező indexdefiníció és parsingMode explicit mezőleképezések megadása nélkül van beállítva jsonLines , így a leképezések úgy néznek ki, mint az első példában, tegyük fel, hogy a blobtároló blobokat a következő struktúrával rendelkezik:

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" 

Figyelje meg, hogy minden dokumentum tartalmazza az id index mezőjeként key definiált mezőt. Ilyen esetben annak ellenére, hogy egy egyedi dokumentum AzureSearch_DocumentKey jön létre, a rendszer nem használja a dokumentum "kulcsaként". A mező értéke id inkább a key mezőre van megfeleltetve

Az előző példához hasonlóan ez a leképezés nem eredményez négy dokumentum megjelenítését az indexben, mert a id mező nem egyedi a blobok között. Ebben az esetben minden olyan JSON-bejegyzés, amely egy új dokumentum feltöltése helyett a meglévő dokumentum egyesítését adja meg id , az index állapota pedig a legújabb olvasási bejegyzést tükrözi a megadottval id.

Következő lépések

Ha még nem ismeri a blobindexelés alapvető struktúráját és munkafolyamatát, először tekintse át az Azure Blob Storage és az Azure AI Search indexelését. A különböző blobtartalmak elemzési módjairól az alábbi cikkekben olvashat bővebben.