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

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

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

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

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

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

Основные понятия: единицы поиска, реплики, разделы

Емкость выражается в единицах поиска , которые можно выделить в сочетаниях секций и реплик.

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

Когда следует расширять емкость

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

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

Рекомендации по определению того, следует ли добавлять емкость:

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

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

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

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

Обновление емкости

Некоторые возможности поиска ИИ Azure доступны только для новых служб. Одна из таких возможностей — это более высокая емкость хранилища, которая применяется к службам, созданным после апреля 2024 года. Тем не менее, если вы создали службу до апреля 2024 года, вы можете получить более высокую емкость без повторного восстановления службы, выполнив однократное обновление. Дополнительные сведения см. в статье об обновлении службы поиска.

Изменение емкости

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

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

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

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

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

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

   

3. С помощью ползунка увеличивайте и уменьшайте число секций. Нажмите кнопку "Сохранить".

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

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

   

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

   

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

   

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

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

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

• Хранилище секций
• Индексы
• Векторы
• Индексаторы
• Общие ресурсы частных ссылок
• Синонимы
• Псевдонимы индекса
• Регулирование семантического ранга

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

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

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

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

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

   

4. На странице "Выбор ценовой категории " выберите более высокий уровень из списка. В настоящее время можно переходить только между уровнями: Базовый, S1, S2 и S3. Другие ценовые категории недоступны и отображаются неактивными.

5. Чтобы перейти на более высокий уровень, нажмите кнопку "Выбрать".

   

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

   

Как обрабатываются запросы на масштабирование

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

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

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

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

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

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

Чтобы устранить эту ошибку, проверьте состояние службы, чтобы проверить статус предоставления.

1. Чтобы получить состояние службы, используйте REST API управления, Azure PowerShell или Azure CLI .
2. Вызовите Get Service (REST) или аналогичный для PowerShell или CLI.
3. Проверьте ответ "provisioningState": "подготовка"

Если состояние — "Подготовка", ожидайте завершения запроса. Перед попыткой выполнения другого запроса состояние должно иметь значение "Успешно" или "Ошибка". Нет статуса для резервного копирования. Резервное копирование является внутренней операцией, и маловероятно, что оно будет фактором в нарушении выполнения упражнения масштабирования.

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

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

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

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

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

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

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

Сведения о тарифах по категориям и валютам см. на странице с ценами на поиск на основе искусственного интеллекта Azure.

Оцените емкость с помощью платного уровня

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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