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

В Поиск с использованием ИИ 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. В соответствии с текущим уровнем выберите "Изменить ценовую категорию".

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

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

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

   

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

   

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

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

   

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

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

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

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

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

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

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

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

² Если служба поиска, похоже, зависла на этапе обеспечения ресурса, проверьте наличие осиротевших индексов, которые неиспользуемые, с нулевым числом запросов и без обновлений индекса. Неиспользуемый индекс может блокировать изменения емкости службы. В частности, найдите индексы, зашифрованные 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 для функциональности запросов и индексации данных (чтение и запись данных).

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

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