Оценка емкости службы поиска, а также управление ею

Поиск с использованием ИИ Azure предлагает две модели ценообразования, которые обрабатывают емкость по-разному:

• Выделенный: планируйте емкость, задавая количество реплик и разделов и выбирая уровень обслуживания.

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

• Бессерверные (предварительная версия): служба автоматически управляет емкостью на основе ограничений использования и служб. Вам не нужно предварительно подготавливать емкость. Вместо этого оптимизируйте эффективность рабочей нагрузки для управления затратами.

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

Дополнительные сведения см. в статье о том, как:

• Планирование затрат и управление ими
• Выбор модели ценообразования и уровня служб
• Оптимизация затрат с помощью модели ценообразования без сервера

Планирование ресурсов для выделенной модели

В выделенной модели вы выделяете ресурсы с помощью поисковых единиц (SU):

• Единица поиска (SU) = реплики × разделы
• Реплика: Копии поискового движка. Обеспечивает пропускную способность запросов и высокую доступность.
• Раздел: единицы хранения. Предоставляет пропускную способность хранения и индексирования.

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

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

Физические характеристики реплик и секций, например скорость обработки и операций ввода-вывода на диск, зависят от уровня служб. В стандартной службе поиска реплики и секции быстрее и больше, чем в базовой службе.

Когда добавлять емкость для выделенной модели

Рассмотрите возможность добавления реплик или разделов, если:

• Задержка запросов увеличивается или критерии соглашения об уровне обслуживания не соблюдаются.
• Частота ошибок HTTP 503 (служба недоступна) увеличивается.
• Частота ошибок HTTP 429 («Слишком много запросов») увеличивается, что указывает на ограничение частоты запросов.
• Ожидается большой объем запросов.
• Задания индексирования выполняются медленно или отстают.
• Недостаточно пропускной способности хранилища или индексирования.

Руководство по масштабированию:

• Добавьте реплики для повышения пропускной способности запросов и доступности.
• Добавьте секции для повышения производительности хранилища и индексирования.
• Для рабочих нагрузок с большим объемом запросов обычно требуется больше реплик.
• Большие индексы могут требовать дополнительных реплик для поддержания производительности.

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

Одна служба должна иметь достаточно ресурсов для обработки всех рабочих нагрузок (индексирования и запросов). Ни одна рабочая нагрузка не выполняется в фоновом режиме. Вы можете запланировать индексирование на время, когда запросы происходят естественным образом реже, однако служба не отдает приоритет одной задаче перед другой. Кроме того, определенный объем избыточности повышает производительность запросов при внутреннем обновлении служб или узлов.

Как правило, приложениям поиска требуется больше реплик, чем разделов, особенно когда операции службы смещены в сторону рабочих нагрузок запросов. Каждая реплика — это копия вашего индекса, поэтому служба может распределять запросы между несколькими копиями для балансировки нагрузки. Поиск с использованием ИИ Azure управляет всеми балансировками нагрузки и репликацией индекса. Вы можете в любое время изменить количество реплик, выделенных для вашего сервиса. Можно выделить до 12 реплик для службы поиска уровня "Стандартный" и до 3 реплик для службы поиска уровня "Базовый". Вы можете выполнить распределение реплик через портал Azure или с помощью одного из программных способов.

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

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

Ограничения служб и допустимые диапазоны масштабирования см. в статье:

• Ограничения службы для уровней и SKU
• Выбор модели ценообразования и уровня служб

Как управлять емкостью и настраивать ее

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

При масштабировании службы поиска можно выбрать один из следующих средств и подходов:

• портал Azure
• Azure PowerShell
• Azure CLI;
• REST API управления

Чтобы увеличить или уменьшить емкость службы, у вас есть два варианта:

• Добавление или удаление секций и реплик
• Изменение ценовой категории

Добавление или удаление секций и реплик

1. Перейдите в службу поиска на портале Azure.

2. В левой области выберите Параметры>Масштаб.

   На следующем снимке экрана показана служба «Стандартная», настроенная с одной репликой и разделом. В формуле внизу показано, сколько единиц поиска используется (1). Если бы цена за единицу составляла 1000 рублей (это произвольное, а не реальное значение), ежемесячная стоимость эксплуатации этой службы составляла бы в среднем 1000 рублей.

   

3. Используйте ползунок для увеличения или уменьшения количества секций, а затем нажмите кнопку "Сохранить".

   В этом примере добавляются вторая реплика и секция. Обратите внимание на количество единиц поиска; теперь их четыре, так как формула расчета стоимости — это количество реплик, умноженное на количество разделов (2 x 2). Удвоение емкости ведет к увеличению затрат на службу более чем вдвое. Если бы цена за единицу поиска составляла 1000 рублей, новый ежемесячный счет теперь составлял бы 4000 рублей.

   Для текущих затрат на единицу каждого уровня перейдите на страницу цен.

   

4. Проверьте уведомления, чтобы убедиться, что операция запущена.

   

   Эта операция может занять несколько часов. Она происходит в фоновом режиме, поэтому служба поиска остается полностью операционной и доступной для операций чтения и записи.

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

   

Изменение ценовой категории

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

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

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

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

1. Перейдите в службу поиска на портале Azure.

2. В левой области выберите Параметры>Масштаб.

3. В соответствии с текущим уровнем выберите "Изменить ценовую категорию".

   Снимок экрана кнопки «Изменить ценовой уровень» на портале Azure.

4. На странице "Выбор ценовой категории " выберите другой уровень из списка.

   Вы можете переключаться между Basic, S1, S2 и S3, но вы не можете переключаться на бесплатный, S3HD, L1 или L2. Эти уровни недоступны для выбора и отображаются неактивными.

   

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

   

   Эта операция может занять несколько часов. Она происходит в фоновом режиме, поэтому служба поиска остается полностью операционной и доступной для операций чтения и записи.

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

   

Обработка запросов масштабирования для выделенной модели

Когда служба поиска получает запрос на масштабирование, он:

1. Проверяет, допустимый ли запрос.
2. Запускает резервное копирование данных и системных сведений.
3. Проверяет, находится ли служба в состоянии предоставления ресурсов (в настоящее время добавление или удаление реплик или разделов).
4. Начинается обеспечение

Масштабирование службы может занять несколько минут до нескольких часов в зависимости от размера службы и области запроса. Длительность резервного копирования также зависит от объема данных и количества секций и реплик.

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

Ошибки при масштабировании

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

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

² Если служба поиска, похоже, зависла на этапе обеспечения ресурса, проверьте наличие осиротевших индексов, которые неиспользуемые, с нулевым числом запросов и без обновлений индекса. Неиспользуемый индекс может блокировать изменения емкости службы. В частности, найдите индексы, зашифрованные CMK , ключи которых больше не допустимы. Удалите индекс или восстановите ключи, чтобы вернуть индекс обратно в сеть и разблокировать операцию масштабирования.

сочетания партиций и реплик

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

Базовые службы поиска имеют меньшее количество единиц поиска.

• В службах поиска, созданных до 3 апреля 2024 года, базовые службы могут иметь ровно один раздел и до трех реплик для максимального ограничения в три SU. Единственным ресурсом, который можно изменять, являются реплики. Однако вы можете увеличить число разделов, обновив службу.

• В службах поиска, созданных после 3 апреля 2024 г. в поддерживаемых регионах, базовые службы могут иметь до трех разделов и трех реплик. Максимальное ограничение SU составляет девять для поддержки полного набора разделов и реплик.

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

Тарифы на выставление счетов по уровням и валютам см. на странице цен Поиск с использованием ИИ Azure.

Оцените емкость с использованием уровня модели ценообразования Dedicated

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

Оценка емкости на оплачиваемом уровне, базовом или более высоком. Уровень "Бесплатный" выполняется на физических ресурсах, общих несколькими клиентами, и зависит от факторов, выходящих за рамки вашего контроля. Только выделенные ресурсы оплачиваемой службы поиска могут вместить больше времени выборки и обработки для более реалистичных оценок количества индексов, размеров и томов запросов во время разработки.

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

   Служба поиска подвергается ограничениям объектов (максимальное количество индексов, индексаторов, наборов навыков и т. д.) и ограничений хранения. Любое ограничение, достигнутое первым, является эффективным ограничением.

2. Создайте службу на оплачиваемом уровне. Уровни оптимизированы для определенных рабочих нагрузок. Например, оптимизированный для хранилища уровень имеет ограничение в 10 индексов, так как он предназначен для поддержки низкого количества больших индексов.

   • Если вы не уверены относительно масштабов нагрузки, начните с низкого уровня: "Базовый" или S1.

   • Если при тестировании предполагается масштабная индексация и высокая интенсивность запросов, начинайте сразу с уровня S2 или даже S3.

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

3. Создайте исходный индекс , чтобы определить, как исходные данные преобразуется в индекс. Это единственный способ оценки размера индекса. Атрибуты определений полей влияют на требования к физическому хранилищу:

   • Для поиска ключевых слов поля маркировки в качестве фильтруемых и сортируемых увеличивает размер индекса.

   • Для поиска векторов можно задать параметры для уменьшения размера вектора.

4. Монитор хранилища, ограничений службы, тома запросов и задержки на портале Azure. На портале Azure отображаются запросы в секунду, запросы с ограничением и задержка поиска. Эти значения помогут вам решить, выбран ли нужный уровень.

5. Добавьте реплики для обеспечения высокой доступности или для снижения производительности медленных запросов.

   Рекомендаций по количеству реплик, необходимых для того или иного уровня интенсивности запросов, не существует. Производительность запросов зависит от сложности запроса и конкурирующих рабочих нагрузок. Хотя добавление реплик явно приводит к повышению производительности, результат не является строго линейным: добавление трех реплик не гарантирует тройную пропускную способность. Рекомендации по оценке QPS для решения см. в статье "Анализ производительности и мониторинг запросов".

Для инвертированного индекса размер и сложность определяются содержимым, а не обязательно объемом данных, которые вы передаете в него. Большой источник данных с высокой избыточностью может привести к созданию меньшего индекса, чем для меньшего набора данных, который содержит сильно изменяемое содержимое. Таким образом, редко бывает возможным определить размер индекса на основе размера исходного набора данных.

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

Рекомендации по соглашению на уровне обслуживания

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

• Два или более реплик удовлетворяют соглашениям об уровне обслуживания запросов (чтение).

• Три или более реплик удовлетворяют SLA для функциональности запросов и индексации данных (чтение и запись данных).

Количество разделов не влияет на соглашения об уровне обслуживания.

Оптимизация затрат на бессерверную модель

В модели ценообразования без сервера:

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

Дополнительные сведения об ограничениях для бессерверной модели см. в разделе "Ограничения службы".

Выставление счетов основано на двух измерениях:

• Использование вычислительных ресурсов (CUS): Плата взимается на основе операций запроса и индексирования.
• Индексированное хранилище: Плата за ГБ в месяц.

Поскольку выставление счетов основано на использовании, стоимость напрямую связана с использованием:

• Сложные запросы используют больше вычислительных ресурсов.
• Неэффективная схема увеличивает затраты на индексирование и запросы.
• Плохие шаблоны запросов с большими или часто обновляемыми индексами повышают объем хранилища и использования вычислительных ресурсов.

Оптимизация эффективности рабочей нагрузки

Поскольку неэффективность отображается как стоимость в бессерверной модели, вы платите больше за ту же работу, если вы не практикуете разработку с учетом рабочей нагрузки. Лучший способ управления бессерверными затратами — эффективно разрабатывать индексы и запросы с самого начала.

Чтобы разработать рабочие нагрузки для повышения эффективности при использовании модели ценообразования без сервера, рассмотрите следующее:

Проектирование индекса

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

Шаблоны запросов

• Используется $select для ограничения возвращаемых полей.
• Применяйте фильтры на раннем этапе, чтобы сократить объём результатов.
• Избегайте глубокого разбиения по страницам ($skip).
• Отдавайте предпочтение целевым запросам, а не широким полнотекстовым запросам.
• Тщательно используйте гибридный поиск из-за более высокой стоимости вычислений.

Monitoring

• Отслеживайте использование CU, чтобы выявлять дорогостоящие запросы.
• Отслеживайте рост хранилища и удаляйте неиспользуемые данные.

В бессерверном случае повышение производительности (быстрее, более целевых запросов) обычно снижает затраты.

Дополнительные сведения см. в статье Оптимизация затрат с помощью бессерверной модели ценообразования в Поиск с использованием ИИ Azure.

Особенности региональных мощностей

Емкость и доступность могут отличаться в зависимости от поддерживаемого региона. Некоторые регионы могут иметь ограничения на подготовку новых служб или масштабирование существующих.

Если предпочтительный регион Поиск с использованием ИИ Azure недоступен из-за ограничений мощности, см. раздел Как обрабатывать ограничения региональной мощности в Поиск с использованием ИИ Azure.

Следующие шаги