Indeksowanie obiektów blob i plików w celu utworzenia wielu dokumentów wyszukiwania
Dotyczy: indeksatory obiektów blob, indeksatory plików
Domyślnie indeksator traktuje zawartość obiektu blob lub pliku jako pojedynczy dokument wyszukiwania. Jeśli chcesz bardziej szczegółową reprezentację w indeksie wyszukiwania, możesz ustawić wartości parsingMode , aby utworzyć wiele dokumentów wyszukiwania z jednego obiektu blob lub pliku. Wartości parsingMode , które powodują wiele dokumentów wyszukiwania, obejmują delimitedText (w przypadku plików CSV) i jsonArrayjsonLines (dla formatu JSON).
W przypadku korzystania z dowolnego z tych trybów analizowania nowe dokumenty wyszukiwania, które pojawiają się, muszą mieć unikatowe klucze dokumentów i pojawia się problem podczas określania, skąd pochodzi ta wartość. Obiekt blob nadrzędny ma co najmniej jedną unikatową wartość w postaci metadata_storage_path propertyelementu , ale jeśli współtworzy tę wartość do więcej niż jednego dokumentu wyszukiwania, klucz nie jest już unikatowy w indeksie.
Aby rozwiązać ten problem, indeksator obiektów blob generuje unikatowy AzureSearch_DocumentKey identyfikator każdego podrzędnego dokumentu wyszukiwania utworzonego na podstawie pojedynczego obiektu nadrzędnego obiektu blob. W tym artykule wyjaśniono, jak działa ta funkcja.
Klucz dokumentu jeden do wielu
Każdy dokument w indeksie jest jednoznacznie identyfikowany przez klucz dokumentu. Jeśli nie określono trybu analizowania i jeśli w definicji indeksatora nie ma jawnego mapowania pól dla klucza dokumentu wyszukiwania, indeksator obiektów blob automatycznie mapuje metadata_storage_path property element jako klucz dokumentu. To domyślne mapowanie gwarantuje, że każdy obiekt blob jest wyświetlany jako odrębny dokument wyszukiwania i zapisuje krok konieczności samodzielnego utworzenia tego mapowania pól (zwykle tylko pola o identycznych nazwach i typach są automatycznie mapowane).
W scenariuszu dokumentu wyszukiwania jeden do wielu niejawny klucz dokumentu oparty na metadata_storage_path property nie jest możliwy. Aby obejść ten problem, usługa Azure AI Search może wygenerować klucz dokumentu dla każdej jednostki wyodrębnionej z obiektu blob. Wygenerowany klucz ma nazwę AzureSearch_DocumentKey i jest dodawany do każdego dokumentu wyszukiwania. Indeksator śledzi "wiele dokumentów" utworzonych na podstawie każdego obiektu blob i może kierować aktualizacje do indeksu wyszukiwania, gdy dane źródłowe zmieniają się wraz z upływem czasu.
Domyślnie, gdy nie określono jawnych mapowań pól dla pola indeksu klucza, AzureSearch_DocumentKey element jest do niego mapowany przy użyciu base64Encode funkcji mapowania pól.
Przykład
Przyjmij definicję indeksu z następującymi polami:
idtemperaturepressuretimestamp
Kontener obiektów blob ma obiekty blob z następującą 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" }
Podczas tworzenia indeksatora i ustawiania parametru parsingMode na jsonLines — bez określania jawnych mapowań pól dla pola klucza, następujące mapowanie jest stosowane niejawnie.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Ta konfiguracja powoduje uściślanie kluczy dokumentów, podobnie jak na poniższej ilustracji (identyfikator zakodowany w formacie base64 skrócił się do zwięzłości).
| ID | temperature | ciśnienie | timestamp |
|---|---|---|---|
| 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 |
Niestandardowe mapowanie pól dla pola klucza indeksu
Zakładając, że ta sama definicja indeksu co w poprzednim przykładzie, załóżmy, że kontener obiektów blob ma obiekty blob z następującą strukturą:
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"
Podczas tworzenia indeksatora z delimitedTextparsingMode może wydawać się naturalne, aby skonfigurować funkcję mapowania pól w polu klucza w następujący sposób:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Jednak to mapowanie nie spowoduje wyświetlania czterech dokumentów w indeksie, ponieważ recordid pole nie jest unikatowe w obiektach blob. W związku z tym zalecamy użycie niejawnego mapowania pól zastosowanego z AzureSearch_DocumentKey właściwości do pola indeksu klucza dla trybów analizowania "jeden do wielu".
Jeśli chcesz skonfigurować jawne mapowanie pól, upewnij się, że pole źródłowe jest odrębne dla każdej jednostki we wszystkich obiektach blob.
Uwaga
Podejście stosowane przez AzureSearch_DocumentKey zapewnienie unikatowości dla wyodrębnionej jednostki podlega zmianie i dlatego nie należy polegać na jej wartości dla potrzeb aplikacji.
Określanie pola klucza indeksu w danych
Zakładając, że ta sama definicja indeksu co w poprzednim przykładzie i parsingMode jest ustawiona na jsonLines wartość bez określania jawnych mapowań pól, tak aby mapowania wyglądały jak w pierwszym przykładzie, załóżmy, że kontener obiektów blob ma obiekty blob z następującą strukturą:
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"
Zwróć uwagę, że każdy dokument zawiera id pole zdefiniowane jako key pole w indeksie. W takim przypadku, mimo że zostanie wygenerowany unikatowy AzureSearch_DocumentKey dokument, nie będzie on używany jako "klucz" dla dokumentu. Zamiast tego wartość id pola zostanie zamapowana na key pole
Podobnie jak w poprzednim przykładzie, to mapowanie nie spowoduje wyświetlania czterech dokumentów w indeksie, ponieważ id pole nie jest unikatowe w obiektach blob. W takim przypadku dowolny wpis JSON, który określa id , spowoduje scalenie istniejącego dokumentu zamiast przekazania nowego dokumentu, a stan indeksu będzie odzwierciedlać najnowszy wpis odczytu z określonym idelementem .
Następne kroki
Jeśli nie znasz jeszcze podstawowej struktury i przepływu pracy indeksowania obiektów blob, najpierw zapoznaj się z tematem Indeksowanie usługi Azure Blob Storage za pomocą usługi Azure AI Search . Aby uzyskać więcej informacji na temat trybów analizowania dla różnych typów zawartości obiektów blob, zapoznaj się z następującymi artykułami.