Индексы в Когнитивном поиске Azure

В Когнитивном поиске Azure индекс — это содержимое, доступное для поиска, доступное поисковой системе для индексирования, полнотекстового поиска и отфильтрованных запросов. Индекс определяется схемой и сохраняется в службе поиска с импортом данных следующим шагом. Это содержимое существует в службе поиска, кроме основных хранилищ данных, которые необходимы для времени отклика в миллисекундах, ожидаемого в современных приложениях. За исключением определенных сценариев индексирования, служба поиска никогда не будет подключаться к локальным данным или запрашивать их.

Если вы создаете индекс поиска и управляете им, эта статья поможет вам понять следующее:

  • Содержимое (документы и схема)
  • Физическое представление
  • Базовые операции

Предпочитаете быть практическими сразу? См. раздел "Создание индекса поиска ".

Содержимое индекса поиска

В Когнитивном поиске индексы содержат документы поиска. Документ представляет собой единый блок доступных для поиска данных в индексе. Например, у розничного продавца может быть документ для каждого продукта, в новостной организации может быть документ для каждой статьи, у туристического сайта может быть документ для каждого отеля и назначения и т. д. Можно сравнить эти понятия с более знакомыми эквивалентными понятиями баз данных: индекс поиска напоминает таблицу, а документы — строки в ней.

Структура документа определяется схемой индекса, как показано ниже. Коллекция "fields" обычно является самой большой частью индекса, где каждое поле называется, назначается тип данных и приписывается допустимым поведением, определяющим его использование.

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "synonymMaps": [ "name_of_synonym_map" ] (optional, only one synonym map per field is currently supported)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ }
  }
}

Другие элементы свернуты для краткости, но следующие ссылки могут предоставить подробные сведения:

  • Средства подбора поддерживают запросы вперед по типу, такие как автозавершение
  • Профили оценки используются для настройки релевантности
  • Анализаторы используются для обработки строк в токены в соответствии с лингвистическими правилами или другими характеристиками, поддерживаемыми анализатором.
  • Удаленный скрипт между источниками (CORS) используется для приложений, которые выдает запросы из разных доменов.
  • Ключ шифрования используется для двойного шифрования конфиденциального содержимого в индексе.

Определения полей

Поисковый документ определяется коллекцией "fields" в тексте запроса create Index. Вам потребуются поля для идентификации документов (ключей), хранения текста с поддержкой поиска и полей для поддержки фильтров, аспектов и сортировки. Кроме того, могут потребоваться поля для данных, которые пользователь никогда не видит. Например, могут потребоваться поля для прибыли или маркетинговых рекламных акций, которые можно использовать для изменения ранжирования поиска.

Если входящие данные являются иерархическими по своей природе, их можно представить в индексе как сложный тип, используемый для представления вложенных структур. Встроенный пример набора данных "Гостиницы" иллюстрирует сложный тип с полем адреса (содержит несколько вложенных полей), которое имеет единственную связь с каждой гостиницей, и со сложной коллекцией номеров, в которой с каждой гостиницей связано несколько номеров.

Атрибуты полей

Атрибуты поля определяют, как используется поле, например, используется ли полнотекстовый поиск, фасетная навигация, операции сортировки и т д.

Строковые поля часто отмечены как searchable (доступные для поиска) и retrievable (доступные для получения). Для сужения результатов поиска используются поля sortable (сортируемое), filterable (фильтруемое) и facetable (аспектируемое).

attribute Описание
searchable (доступное для поиска) Полнотекстовый поиск, подлежащий лексическому анализу, такому как разбиения на слова во время индексации. Если, например, задать для поля, поддерживающего поиск, значение sunny day (солнечный день), оно будет разделено на элементы sunny и day. Дополнительные сведения см. в статье Как работает полнотекстовый поиск в службе поиска Azure.
filterable (фильтруемое) Указывается в запросах $filter. Для фильтруемых полей типа Edm.String и Collection(Edm.String) не выполняется разбиение на слова, поэтому они могут попасть в результаты поиска только по точному совпадению. Например, если для такого поля задать значение sunny day, запрос $filter=f eq 'sunny' не вернет совпадений, а запрос — $filter=f eq 'sunny day' вернет.
sortable (сортируемое) По умолчанию система сортирует результаты по их оценке, однако можно настроить сортировку на основе полей в документах. Поля типа Collection(Edm.String) не могут иметь атрибут sortable.
facetable (аспектируемое) Обычно используется в представлении результатов поиска, включающих количество обращений по категориям (например, отелей в определенном городе). Этот параметр не предназначен для использования с полями типа Edm.GeographyPoint. Поля типа Edm.String, которые имеют атрибуты filterable, sortable или facetable, могут иметь длину не более 32 КБ. Дополнительные сведения см. в статье Create Index (Azure Search Service REST API) (Создание индекса в REST API службы Поиска Azure).
key (ключ) Уникальный идентификатор для документов в индексе. Только одно поле должно быть выбрано ключевым и оно должно иметь тип Edm.String.
retrievable (доступное для получения) Определяет, включается ли поле в возвращаемые поиском результаты. Этот атрибут полезен, когда поле (например, показатель прибыльности) нужно использовать для фильтрации, сортировки или оценки, но оно не должно отображаться конечному пользователю. У полей с установленным свойством true for key .

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

Примечание

API, используемые для создания индекса, имеют различные поведения по умолчанию. Для REST API по умолчанию включено большинство атрибутов (например, для строковых полей используются searchable (доступное для поиска) и retrievable (доступное для получения)), и часто их нужно настраивать только в том случае, если их необходимо отключить. В пакете SDK для .NET все наоборот. Для каждого свойства, не заданного явным образом, по умолчанию соответствующее поведение поиска отключено, если не включить его специально.

Физическая структура и размер

В Когнитивном поиске Azure физическая структура индекса в значительной степени является внутренней реализацией. Вы можете получить доступ к своей схеме, запросить его содержимое, отслеживать его размер и управлять емкостью, но сами кластеры (индексы, сегменты и другие файлы и папки) управляются корпорацией Майкрософт.

Размер индекса можно отслеживать на вкладке "Индексы" на портале Azure или путем выдачи запроса GET INDEX к службе поиска. Вы также можете отправить запрос статистики службы и проверить значение размера хранилища.

Размер индекса определяется следующими значениями:

  • Количество и композиция документов
  • Атрибуты для отдельных полей
  • Конфигурация индекса (в частности, включение средств подбора)

Структура и количество документов определяются тем, что вы выбираете для импорта. Помните, что индекс поиска должен содержать только доступное для поиска содержимое. Если исходные данные содержат двоичные поля, опустите эти поля, если вы не используете обогащение ИИ для взлома и анализа содержимого для создания текстовых сведений, доступных для поиска.

Атрибуты полей определяют поведение. Для поддержки этих поведений процесс индексирования создает необходимые структуры данных. Например, "searchable" вызывает полнотекстовый поиск, который сканирует инвертированные индексы для маркеризованного термина. Напротив, атрибут "filterable" или "sortable" поддерживает итерацию по неизмененной строке. В примере в следующем разделе показаны варианты размера индекса на основе выбранных атрибутов.

Средства подбора — это конструкции, поддерживающие запросы вперед по типу или автозавершения. Таким образом, при включении средства подбора процесс индексирования создаст структуры данных, необходимые для подробных совпадений символов. Средства подбора реализуются на уровне поля, поэтому выберите только те поля, которые являются разумными для типа вперед.

Пример демонстрации последствий хранения атрибутов и средств подбора

На следующем снимке экрана показаны шаблоны хранения индекса, полученные в результате различных сочетаний атрибутов. Индекс основан на примере индекса недвижимости, который можно легко создать с помощью мастера импорта данных и встроенных примеров данных. Хотя схемы индексов не показаны, атрибуты можно определить на основе имени индекса. Например, для индекса realestate-searchable выбран только атрибут searchable, для индекса realestate-retrievable выбран только атрибут retrievable и т. д.

Index size based on attribute selection

Хотя эти варианты индекса являются несколько искусственными, мы можем ссылаться на них для широкого сравнения того, как атрибуты влияют на хранилище:

  • "Извлекаемый" не влияет на размер индекса.
  • "фильтруемый", "сортируемый", "аспектируемый" потребляют больше хранилища.
  • Средство подбора имеет большой потенциал для увеличения размера индекса, но не столько, сколько на снимке экрана(все поля, которые могут быть выбраны с учетом средства подбора, что не является вероятным сценарием в большинстве индексов).

Кроме того, в приведенной выше таблице не отражено влияние анализаторов. Если использовать создатель лексем edgeNgram для хранения буквальных последовательностей символов (a, ab, abc, abcd), размер индекса будет больше, чем при использовании стандартного анализатора.

Основные операции и взаимодействие

Теперь, когда у вас есть более полное представление о том, что такое индекс, в этом разделе приводятся операции времени выполнения индекса, включая подключение и обеспечение безопасности одного индекса.

Примечание

При управлении индексом следует помнить, что нет поддержки портала или API для перемещения или копирования индекса. Вместо этого клиенты обычно указывают свое решение развертывания приложений в другой службе поиска (при использовании того же имени индекса) или пересматривают имя, чтобы создать копию в текущей службе поиска, а затем создать ее.

Изоляция индекса

В Когнитивном поиске вы будете работать с одним индексом за раз, где все операции, связанные с индексом, нацелены на один индекс. Нет понятия о связанных индексах или присоединении независимых индексов для индексирования или запроса.

Непрерывная доступность

Индекс постоянно доступен без возможности приостановить или перевести его в автономный режим. Так как он предназначен для непрерывной работы, любые обновления его содержимого или дополнения к самому индексу происходят в режиме реального времени. В результате запросы могут временно возвращать неполные результаты, если запрос совпадает с обновлением документа.

Обратите внимание, что непрерывность запросов существует для операций с документами (обновление или удаление) и для изменений, которые не влияют на существующую структуру и целостность текущего индекса (например, добавление новых полей). Если необходимо внести структурные обновления (изменение существующих полей), они обычно управляются с помощью рабочего процесса удаления и перестроения в среде разработки или путем создания новой версии индекса в рабочей службе.

Чтобы избежать перестроения индекса, некоторые клиенты, внося небольшие изменения, выбирают "версию" поля, создавая новый, который сосуществует вместе с предыдущей версией. Со временем это приводит к потерянным содержимому в виде устаревших полей или устаревших определений пользовательских анализаторов, особенно в производственном индексе, который требуется реплицировать. Эти проблемы можно устранить при запланированных обновлениях индекса в рамках управления жизненным циклом индекса.

Подключение к конечной точке и безопасность

Все запросы индексирования и запросов предназначены для индекса. Конечные точки обычно являются одной из следующих:

Конечная точка Управление подключением и доступом
<your-service>.search.windows.net/indexes Ориентирована на коллекцию индексов. Используется при создании, перечислении или удалении индекса. Права администратора необходимы для этих операций, доступные с помощью ключей API администратора или роли участника поиска.
<your-service>.search.windows.net/indexes/<your-index>/docs Ориентирована на коллекцию документов одного индекса. Используется при запросе к индексу или обновлению данных. Для запросов достаточно прав на чтение и доступны с помощью ключей API запросов или роли чтения данных. Для обновления данных требуются права администратора.

Дальнейшие действия

Вы можете получить практический опыт создания индекса с помощью практически любого примера или пошагового руководства для Когнитивного поиска. Для начала можно выбрать любое краткое руководство в содержании.

Вы также захотите ознакомиться с методологиями загрузки индекса с данными. Стратегии определения индекса и импорта данных создаются совместно. В следующих статьях содержатся дополнительные сведения о создании и загрузке индекса.