Indizieren von Blobs und Dateien zum Generieren mehrerer Suchdokumente
Gilt für: Blobindexer, Dateiindexer
Standardmäßig behandelt ein Indexer die Inhalte eines Blobs oder einer Datei als ein Suchdokument. Wenn Sie in einem Suchindex eine differenziertere Darstellung benötigen, können Sie Werte vom Typ parsingMode festlegen, um mehrere Suchdokumente für ein einzelnes Blob oder eine Datei zu erstellen. Zu den Werten vom Typ parsingMode, die zahlreiche Suchdokumente ergeben, zählen delimitedText (für CSV) und jsonArray oder jsonLines (für JSON).
Bei Verwendung eines dieser Analysemodi müssen die neu generierten Suchdokumente über eindeutige Dokumentschlüssel verfügen, und es gibt ein Problem bei der Bestimmung, woher der Wert stammt. Das übergeordnete Blob verfügt zwar über mindestens einen eindeutigen Wert in Form von metadata_storage_path property, wenn dieser Wert jedoch in mehreren Suchdokumenten verwendet wird, ist der Schlüssel im Index nicht mehr eindeutig.
Daher wird vom Blobindexer ein Azure Search-Dokumentschlüssel (AzureSearch_DocumentKey) erstellt, durch den jedes untergeordnete Suchdokument, das auf der Grundlage des einzelnen übergeordneten Blobs erstellt wird, eindeutig identifizierbar ist. In diesem Artikel erfahren Sie, wie dieses Feature funktioniert.
1:n-Dokumentschlüssel
Jedes Dokument in einem Index wird eindeutig durch einen Dokumentschlüssel identifiziert. Ohne Angabe eines Analysemodus und ohne explizite Feldzuordnung in der Indexerdefinition für den Suchdokumentschlüssel wird automatisch metadata_storage_path property als Dokumentschlüssel zugeordnet. Diese Standardzuordnung stellt sicher, dass jedes Blob als eindeutiges Suchdokument erkannt wird, und Sie diese Feldzuordnung nicht extra selbst erstellen müssen. (Normalerweise werden nur Felder mit identischem Namen und Typ automatisch zugeordnet.)
In einem 1:n-Suchdokumentszenario ist ein impliziter Dokumentschlüssel, der auf metadata_storage_path property basiert, nicht möglich. Als Problemumgehung kann die Azure KI-Suche einen Dokumentschlüssel für jede einzelne Entität generieren, die aus einem Blob extrahiert wurde. Der generierte Schlüssel erhält den Namen AzureSearch_DocumentKey und wird jedem Suchdokument hinzugefügt. Der Indexer verfolgt die „vielen Dokumente“, die aus jedem Blob erstellt wurden, und kann auf Aktualisierungen des Suchindex abzielen, wenn sich Quelldaten im Laufe der Zeit ändern.
Wenn keine expliziten Feldzuordnungen für das Schlüsselindexfeld angegeben werden, wird mit der Feldzuordnungsfunktion base64Encode standardmäßig AzureSearch_DocumentKey zugeordnet.
Beispiel
Angenommen, Ihre Indexdefinition weist folgende Felder auf:
idtemperaturepressuretimestamp
Und Ihr Blobcontainer enthält Blobs mit folgender Struktur:
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" }
Wenn Sie einen Indexer erstellen und parsingMode auf jsonLines festlegen, ohne explizite Feldzuordnungen für das Schlüsselfeld anzugeben, wird implizit die folgende Zuordnung angewendet.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Dadurch ergeben sich eindeutige Dokumentschlüssel wie in der folgenden Abbildung zu sehen. (Die Base64-codierte ID wurde hier zur besseren Übersichtlichkeit gekürzt.)
| Kennung | Temperatur | pressure | Zeitstempel |
|---|---|---|---|
| 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 |
Benutzerdefinierte Feldzuordnung für das Indexschlüsselfeld
Angenommen, Ihr Blobcontainer enthält Blobs mit folgender Struktur (bei Verwendung der gleichen Indexdefinition wie im vorherigen Beispiel):
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"
Wenn Sie einen Indexer mit parsingMode delimitedText erstellen, kommt es Ihnen möglicherweise natürlich vor, wie folgt eine Feldzuordnungsfunktion für die Schlüsselfelder einzurichten:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Aus dieser Zuordnung ergibt sich jedoch nicht, dass vier Dokumente im Index angezeigt werden, da das Feld recordid nicht blobübergreifend eindeutig ist. Deshalb wird empfohlen, dass Sie die implizite Feldzuordnung verwenden, die von der Eigenschaft AzureSearch_DocumentKey auf das Schlüsselindexfeld für 1:n-Analysemodi angewendet wird.
Wenn Sie eine explizite Feldzuordnung einrichten möchten, sollten Sie sicherstellen, dass sourceField für jede einzelne Entität blobübergreifend eindeutig ist.
Hinweis
Der von AzureSearch_DocumentKey verwendete Ansatz zur Sicherstellung der Eindeutigkeit jeder extrahierten Entität kann sich ändern, und Sie sollten sich deshalb für die Anforderungen Ihrer Anwendung nicht darauf verlassen.
Legen Sie des Indexschlüsselfeld in Ihren Daten fest
Ausgehend von der gleichen Indexdefinition wie im vorhergehenden Beispiel und einem auf jsonLines festgelegten parsingMode, ohne Angabe expliziter Feldzuordnungen, sodass die Zuordnungen dem ersten Beispiel entsprechen, nehmen wir an, dass Ihr Blobcontainer Blobs mit der folgenden Struktur aufweist:
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"
Beachten Sie, dass jedes Dokument das Feld id enthält, das im Index als Feld key definiert ist. In einem solchen Fall wird zwar ein für das Dokument eindeutiger AzureSearch_DocumentKey generiert, dieser wird aber nicht als „Schlüssel“ für das Dokument verwendet. Stattdessen wird dem Feld key der Wert des Felds id zugeordnet
Ähnlich wie beim vorherigen Beispiel ergeben sich aus dieser Zuordnung jedoch keine vier im Index angezeigten Dokumente, da das Feld id nicht blobübergreifend eindeutig ist. Wenn dies der Fall ist, bewirkt jeder JSON-Eintrag, der eine id angibt, eine Zusammenführung des vorhandenen Dokuments statt zum Upload eines neuen Dokuments, und der Status des Index spiegelt den neuesten Leseeintrag mit der angegebenen id wider.
Nächste Schritte
Wenn Sie noch nicht mit der grundlegenden Struktur und dem Workflow der Blobindizierung vertraut sind, sollten Sie zunächst Indizieren von Azure Blob Storage mit Azure KI Search lesen. Weitere Informationen zum Analysemodus für die verschiedenen Blobinhaltstypen finden Sie in den folgenden Artikeln.