Индексирование блобов и файлов для создания нескольких поисковых документов

Область применения: индексаторы BLOB-объектов, индексаторы файлов

По умолчанию индексатор обрабатывает содержимое BLOB или файла как один поисковый документ. Если требуется более детализированное представление в индексе поиска, можно задать значения parsingMode для создания нескольких документов поиска из одного большого двоичного объекта или файла. Значения parsingMode , которые приводят к множеству документов поиска, включают delimitedText (для CSV) и jsonArrayjsonLines (для JSON).

При использовании любого из этих режимов синтаксического анализа новые документы поиска, которые появляются, должны иметь уникальные ключи документов, а проблема возникает при определении того, откуда исходит это значение. Родительский движок имеет по крайней мере одно уникальное значение в виде metadata_storage_path property, но если это значение используется в нескольких документах поиска, ключ больше не является уникальным в индексе.

Чтобы устранить эту проблему, индексатор BLOB-объектов создает AzureSearch_DocumentKey уникальный идентификатор, который однозначно определяет каждый дочерний документ поиска, созданный из одного родительского BLOB-объекта. В этой статье объясняется, как работает эта функция.

Ключ документа "один ко многим"

Ключ документа однозначно идентифицирует каждый документ в индексе. Если режим синтаксического анализа не указан и в определении индексатора для ключа документа поиска нет явного сопоставления полей, индексатор BLOB-объектов автоматически сопоставляет metadata_storage_path property в качестве ключа документа. Это сопоставление по умолчанию гарантирует, что каждый большой двоичный объект представляется как отдельный документ поиска. Это также устраняет необходимость вручную создать это сопоставление полей. Как правило, поля с идентичными именами и типами являются единственными, которые сопоставляются автоматически.

В сценарии поиска "один ко многим" не может быть неявного ключа документа на основе metadata_storage_path property. В качестве обходного решения поиск ИИ Azure может создать ключ документа для каждой отдельной сущности, извлеченной из большого двоичного объекта. Система создает ключ, называемый AzureSearch_DocumentKey, и добавляет его в каждый документ поиска. Индексатор отслеживает "много документов", созданных из каждого BLOB, и может выполнять обновления в индекс поиска по мере изменения исходных данных.

По умолчанию, если явные сопоставления полей для ключевого индекса не указаны, AzureSearch_DocumentKey сопоставляется с ним с использованием функции сопоставления полей base64Encode.

Example

Предположим, что определение индекса включает в себя следующие поля:

• id
• temperature
• pressure
• timestamp

Контейнер BLOB содержит BLOBs со следующей структурой:

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

При создании индексатора и настройке параметра parsingModejsonLines без указания явных сопоставлений полей для ключевого поля следующее сопоставление применяется неявно.

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

Эта настройка приводит к несогласованным ключам документов, как показано на следующем рисунке (сокращенный идентификатор в кодировке Base64 для краткости).

Настраиваемое сопоставление полей для ключевого поля индекса

Предполагая то же определение индекса, что и в предыдущем примере, предположим, что контейнер BLOB-объектов имеет BLOB-объекты со следующей структурой:

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" 

При создании индексатора с delimitedTextparsingMode может показаться естественным настроить функцию сопоставления полей для ключевого поля следующим образом:

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

Однако это сопоставление не приводит к появлению четырех документов в индексе, так как recordid поле не является уникальным для всех объектов. Поэтому рекомендуется воспользоваться неявным сопоставлением полей, примененным из свойства AzureSearch_DocumentKey к ключевому индексному полю для режимов парсинга "один ко многим".

Если вы хотите настроить явное сопоставление полей, убедитесь, что sourceField отличается для каждой отдельной сущности во всех больших двоичных объектах.

Укажите поле ключа индекса в данных

Если задано то же определение индекса, что и в предыдущем примере, и режим синтаксического анализа установлен как jsonLines без указания явных сопоставлений полей, так что они выглядят как в первом примере, предположим, что ваш контейнер BLOB-объектов содержит объекты со следующей структурой:

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" 

Каждый документ содержит id поле, которое определяется как key поле в индексе. В этой ситуации система создает уникальное поле AzureSearch_DocumentKeyfor the document, but it isn't used as the "key." Instead, the value of theidfield is mapped to thekey.

Как и в предыдущем примере, это сопоставление не приводит к отображению четырёх документов в индексе, так как данное id поле не является уникальным для больших двоичных объектов. При возникновении этой ситуации любая запись JSON, указывающая id, вызывает слияние с существующим документом вместо загрузки нового. Индекс затем отражает актуальное состояние записи с указанным id.

Ограничения

Если запись документа в индексе создается из строки в файле, как описано в этой статье, удаление этой строки из файла не автоматически удаляет соответствующую запись из индекса. Чтобы удалить запись документа, необходимо вручную отправить запрос на удаление в индекс с помощью операции удаления REST API.

Дальнейшие шаги

Если вы еще не знакомы с базовой структурой и рабочим процессом индексирования BLOB-объектов, сначала следует просмотреть индексирование хранилища BLOB-объектов Azure с помощью поиска ИИ Azure . Дополнительные сведения о режимах синтаксического анализа для различных типов контента BLOB-объектов см. в следующих статьях.