Индексирование больших двоичных объектов и файлов для создания нескольких документов поиска
Область применения: индексаторы BLOB-объектов, индексаторы файлов
По умолчанию индексатор обрабатывает содержимое большого двоичного объекта или файла как один документ поиска. Если требуется более детализированное представление в индексе поиска, можно задать значения parsingMode для создания нескольких документов поиска из одного большого двоичного объекта или файла. Значения parsingMode, которые позволяют разбить объект на несколько поисковых документов, включают delimitedText (для CSV) и jsonArray или jsonLines (для JSON).
При использовании любого из этих режимов анализа у новых поисковых документов должны быть уникальные ключи, и возникает проблема с источником такого значения. Родительский BLOB-объект содержит по крайней мере одно уникальное значение в форме metadata_storage_path property, но если добавить его в несколько поисковых документов, ключ перестанет быть уникальным в индексе.
Чтобы устранить эту проблему, индексатор BLOB-объектов создает ключ AzureSearch_DocumentKey, однозначно идентифицирующий каждый дочерний поисковый документ, созданный из одного родительского BLOB-объекта. В этой статье объясняется, как работает данная функция.
Ключ документа "один ко многим"
Каждый документ в индексе однозначно определяется ключом документа. Если режим синтаксического анализа не указан, и если в определении индексатора для ключа документа поиска нет явного сопоставления полей, индексатор BLOB-объектов автоматически сопоставляется metadata_storage_path property с ключом документа. Это сопоставление по умолчанию гарантирует, что каждый большой двоичный объект отображается как отдельный документ поиска, и он сохраняет этап создания сопоставления полей самостоятельно (как правило, только поля с одинаковыми именами и типами автоматически сопоставляются).
В сценарии поиска "один ко многим" неявный ключ документа на основе metadata_storage_path property невозможно. В качестве обходного решения поиск ИИ Azure может создать ключ документа для каждой отдельной сущности, извлеченной из большого двоичного объекта. Созданный ключ называется AzureSearch_DocumentKey и добавляется в каждый документ поиска. Индексатор отслеживает "многие документы", созданные из каждого большого двоичного объекта, и может нацеливать обновления на индекс поиска при изменении исходных данных с течением времени.
По умолчанию, если явные сопоставления полей для ключевого поля индекса не указаны, значение AzureSearch_DocumentKey сопоставляется с ним с помощью функции сопоставления полей base64Encode.
Пример
Предположим, что определение индекса со следующими полями:
idtemperaturepressuretimestamp
И контейнер BLOB-объектов содержит большие двоичные объекты со следующей структурой:
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" }
При создании индексатора и настройке параметра parsingMode jsonLines без указания явных сопоставлений полей для ключевого поля следующее сопоставление применяется неявно.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Эта настройка приводит к несогласованным ключам документов, как показано на следующем рисунке (сокращенный идентификатор в кодировке Base64 для краткости).
| ID | Температура | давление | 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 |
Настраиваемое сопоставление полей для ключевого поля индекса
Предположим, что для того же определения индекса, что и в предыдущем примере, контейнер 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"
При создании индексатора с parsingMode delimitedText может показаться естественным решением настроить функцию сопоставления для ключевого поля следующим образом:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Однако это сопоставление не приводит к четырем документам, отображаемым в индексе, так как recordid поле не является уникальным для больших двоичных объектов. Поэтому для режимов анализа "один ко многим" рекомендуется использовать неявное сопоставление полей, применяемое из свойства AzureSearch_DocumentKey к ключевому полю индекса.
Если вы хотите настроить явное сопоставление полей, значение sourceField должно быть уникальным для каждой отдельной сущности во всех BLOB-объектах.
Примечание.
Подход, используемый при AzureSearch_DocumentKey обеспечении уникальности для каждой извлеченной сущности, подлежит изменению, поэтому вы не должны полагаться на его значение для потребностей вашего приложения.
Укажите поле ключа индекса в данных
Если задано то же определение индекса, что и предыдущий пример и синтаксический анализMode , не 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_DocumentKey документ, он не используется в качестве ключа для документа. Скорее, значение id поля сопоставляется с полем key
Как и в предыдущем примере, это сопоставление не приводит к четырем документам, отображаемым в индексе, так как id поле не является уникальным для больших двоичных объектов. В этом случае любая запись JSON, указывающая id результаты слияния для существующего документа, а не отправки нового документа, а состояние индекса отражает последнюю запись чтения с указанным.id
Следующие шаги
Если вы еще не знакомы с базовой структурой и рабочим процессом индексирования BLOB-объектов, сначала следует просмотреть индексирование Хранилище BLOB-объектов Azure с помощью поиска ИИ Azure. Дополнительные сведения о режимах синтаксического анализа для различных типов содержимого BLOB-объектов см. в следующих статьях.