Оценка емкости службы поиска, а также управление ею
В службе "Поиск ИИ Azure" емкость основана на реплика и секциях, которые можно масштабировать до рабочей нагрузки. Реплики — это копии поисковой системы. Секции — это единицы хранения. Каждая новая служба поиска начинается с каждой, но вы можете добавлять или удалять реплика и секции независимо для размещения изменяющихся рабочих нагрузок. Добавление емкости увеличивает затраты на выполнение службы поиска.
Физические характеристики реплик и секций, например скорость обработки и ввод-вывод на диск, зависят от уровня служб. В стандартной службе поиска реплика и секции быстрее и больше, чем в базовой службе.
Изменение емкости не является мгновенным. Для комиссии или списания секций может потребоваться до часа, особенно для служб с большими объемами данных.
При масштабировании службы поиска можно выбрать один из следующих средств и подходов:
Основные понятия: единицы поиска, реплики, секции, сегменты
Емкость выражается в единицах поиска, которые можно распределять по комбинациям секций и реплик, используя базовый механизм сегментирования, обеспечивающий гибкость общей конфигурации.
| Понятие | Определение |
|---|---|
| Единица поиска | Базовый шаг общей доступной емкости (36 единиц). Это также единица выставления счетов для azure AI служба . Для запуска службы требуется минимум одна единица поиска. |
| Реплика | Экземпляры службы поиска, используемые главным образом для распределения операций запросов. На каждой реплике размещается одна копия индекса. При выделении трех реплика у вас есть три копии индекса, доступного для обслуживания запросов. |
| Секция | Служит для физического хранения индексов и ввода-вывода данных для операций чтения и записи (например, при повторном создании или обновлении индексов). Каждая секция содержит срез общего индекса. Если вам выделено три секции, индекс делится на три части. |
| Сегмент | Фрагмент индекса. Поиск ИИ Azure делит каждый индекс на сегменты, чтобы ускорить процесс добавления секций (путем перемещения сегментов в новые единицы поиска). |
На схеме ниже показана связь между репликами, секциями, сегментами и единицами поиска. В этом примере один индекс состоит из четырех единиц поиска с двумя репликами и двумя секциями в службе. В каждой из четырех единиц поиска хранится только половина сегментов индекса. В единицах поиска в левом столбце хранится первая половина сегментов, составляющая первую секцию, в то время как в правом столбце отражена вторая половина сегментов, т. е. вторая секция. Поскольку реплики две, у каждого сегмента индекса по две копии. В единицах поиска в верхней строке хранится одна копия, составляющая первую реплику, а в нижней строке — вторая копия, представляющая вторую реплику.
На схеме выше показан лишь один пример конфигурации. Поддерживаются различные сочетания секций и реплик — всего до 36 единиц поиска.
В службе поиска искусственного интеллекта Azure управление сегментами — это детали реализации и ненастройка, но зная, что индекс сегментирован, помогает понять случайные аномалии в поведении ранжирования и автозаполнения:
Аномалии с ранжированием: рейтинг поиска сначала рассчитывается на уровне сегментов, а затем объединяется в результирующий набор. В зависимости от особенностей содержимого сегментов совпадения из одного сегмента могут ранжироваться выше, чем из другого. Если вы заметите счетчик интуитивно понятных ранжирований в результатах поиска, скорее всего, это связано с эффектами сегментирования, особенно если индексы малы. Чтобы избежать подобных аномалий, перейдите на глобальный расчет рейтингов по всему индексу, но это приведет к снижению производительности.
Аномалии с автозаполнением: запросы автозаполнения, где совпадения подбираются по первым нескольким символам частично введенного ключевого слова, принимают параметр нечеткого соответствия, который допускает небольшие отклонения в написании. Для автозаполнения нечеткие совпадения возможны только по терминам в пределах текущего сегмента. Например, если сегмент содержит "Майкрософт" и частичный термин "micro", поисковая система будет соответствовать в этом сегменте, но не в других сегментах, которые содержат оставшиеся части индекса.
Целевые показатели оценки
Планирование емкости должно включать ограничения объектов (например, максимальное количество индексов, разрешенных в службе) и ограничения хранилища. Уровень служб определяет ограничения объектов и хранилища. Любое ограничение, достигнутое первым, является эффективным ограничением.
Количество индексов и других объектов обычно определяется особенностями бизнеса-процесса и проектирования. Например, у вас может быть несколько версий одного индекса для стадий активной разработки, тестирования и рабочей среды.
Требования к хранилищу определяются размером индексов, которые предполагается создать. Не существует надежных эвристических или общих методов, помогающих провести оценку. Единственный способ определить размер индекса — создать его. Его размер будет зависеть от импортированных данных, текстового анализа и конфигурации индекса, например включения средств подбора, фильтрации и сортировки.
Для полнотекстового поиска первичной структурой данных является структура инвертированного индекса, характеристики которой отличаются от характеристик исходных данных. Размер и сложность инвертированного индекса определяются содержимым, а не количеством данных, которые вы ему передаете. Большой источник данных с высокой избыточностью может привести к созданию меньшего индекса, чем для меньшего набора данных, который содержит сильно изменяемое содержимое. Таким образом, редко бывает возможным определить размер индекса на основе размера исходного набора данных.
Атрибуты индекса, такие как включение фильтров и сортировки, влияют на требования к хранилищу. На хранение также влияет использование средств подбора. Дополнительные сведения см. в статье Атрибуты и размер индекса.
Примечание.
Несмотря на то что оценка будущих потребностей для индексов и хранилища редко бывает точной, ее следует выполнять. Если емкости уровня окажется недостаточно, вам понадобится подготовить новую службу на более высоком уровне, а затем перезагрузить индексы. Возможность обновления службы на месте с одного уровня на другой не поддерживается.
Оценка на уровне "Бесплатный"
Один из способов оценки емкости — начать с бесплатного уровня. Напомним, что на бесплатном уровне службы предлагается до трех индексов, 50 МБ памяти и 2 минуты времени индексирования. С этими ограничениями сложно оценить прогнозируемый размер индекса, но вот общая последовательность действий:
Создайте бесплатную службу.
Подготовьте небольшой репрезентативный набор данных.
Создайте индекс и загрузите данные. Если набор данных может быть размещен в источнике данных Azure с индексаторами, для создания и загрузки индекса можно использовать мастер импорта данных на портале. В противном случае можно использовать REST API для создания индекса и отправки данных. Модель отправки требует, чтобы данные имели вид документов JSON, где поля в документе соответствуют полям в индексе.
Соберите сведения об индексе, например его размер. Функции и атрибуты влияют на хранилище. Например, добавление средств подбора (для запросов с поиском по мере ввода) приведет к увеличению необходимого хранилища.
С тем же набором данных можно попробовать создать несколько версий индекса с различными атрибутами для каждого поля, чтобы увидеть, как различаются требования к хранилищу. Дополнительные сведения см. в разделе "Влияние на размер хранилища" статьи "Создание простого индекса".
Выполнив приблизительную оценку, вы можете увеличить ее из расчета двух индексов (для разработки и рабочей среды), а затем выбрать соответствующий ценовой уровень.
Оценка на основе платного уровня
Выделенные ресурсы поддерживают более обширную выборку и высокую скорость обработки, что позволяет реалистичнее рассчитать количество индексов, их размер и объем запросов в ходе планирования. Некоторые клиенты сразу начинают с платного уровня, а затем периодически повторяют оценку по мере развития проекта.
Ознакомьтесь с ограничениями служб на каждом уровне, чтобы определить, поддерживают ли нижние уровни достаточное для вас количество индексов. Для уровней "Базовый", S1 и S2 ограничения по индексу составляют соответственно 15, 50 и 200. На уровне "Оптимизированный для операций в хранилище" действует ограничение в 10 индексов, поскольку он предназначен для обслуживания небольшого количества очень больших индексов.
Создайте службу на платном уровне:
- Если вы не уверены относительно масштабов нагрузки, начните с низкого уровня: "Базовый" или S1.
- Если при тестировании предполагается масштабная индексация и высокая интенсивность запросов, начинайте сразу с уровня S2 или даже S3.
- Если вы планируете индексировать большой объем данных, а интенсивность запросов будет относительно низкой (как для внутреннего бизнес-приложения), начните с уровня "Оптимизированный для операций в хранилище" L1 или L2.
Создайте начальный индекс, чтобы определить, как исходные данные преобразуются в индекс. Это единственный способ оценки размера индекса.
Отслеживайте хранилище, ограничения служб, объем запросов и задержку в портале. На портале отображаются показатели запросов в секунду, регулируемых запросов и задержки поиска, которые помогают определить, находитесь ли вы на правильном уровне.
Добавьте реплика для обеспечения высокой доступности или снижения производительности медленных запросов.
Рекомендаций по количеству реплик, необходимых для того или иного уровня интенсивности запросов, не существует. Производительность запросов зависит от сложности запроса и конкурирующих рабочих нагрузок. Хотя добавление реплика явно приводит к повышению производительности, результат не является строго линейным: добавление трех реплика не гарантирует тройную пропускную способность. Рекомендации по оценке QPS для решения см. в статье "Анализ производительностии мониторинг запросов".
Примечание.
Требования к хранилищу могут оказаться ниже, если у вас есть данные, которые никто никогда не будут искать. В идеале документы должны содержать только данные, необходимые для поиска. Двоичные данные недоступны для поиска и должны храниться отдельно (возможно, в таблице Azure или хранилище BLOB-объектов). В индекс должно быть добавлено поле для хранения URL-ссылки на внешние данные. Максимальный размер отдельного документа для поиска составляет 16 МБ (или меньше при массовой отправке нескольких документов в одном запросе). Дополнительные сведения см. в разделе "Ограничения службы" в службе "Поиск ИИ Azure".
Рекомендации по объему запросов
Запросы в секунду (QPS) — это важная метрика во время настройки производительности, но для планирования емкости рекомендуется только в том случае, если вы ожидаете высокий объем запросов в начале.
Уровни ценовой категории "Стандартный" способны обеспечивать баланс между репликами и секциями. При увеличении числа запросов вы можете добавлять реплики для балансировки нагрузки или секции для параллельной обработки. После подготовки службы производительность можно настроить.
Если вы с самого начала ожидаете постоянно высоких объемов запросов, следует обратить внимание на более высокие уровни ценовой категории "Стандартный", обслуживаемые более мощным оборудованием. Затем вы можете перевести разделы и реплики в автономный режим или даже перейти на службу более низкого уровня, если такие объемы запросов станут неактуальны. Дополнительные сведения о вычислении пропускной способности запросов см. в разделе "Мониторинг запросов".
Уровни, оптимизированные для операций в хранилище, подходят для рабочих нагрузок с большими объемами данных и предусматривают увеличенное общее хранилище для индексов, когда требования к задержке запросов не очень высоки. При этом вы также можете использовать дополнительные реплики для балансировки нагрузки и дополнительные секции для параллельной обработки. После подготовки службы производительность можно настроить.
Соглашения об уровне обслуживания
Бесплатный уровень и предварительный просмотр функций не охватываются соглашениями об уровне обслуживания (SLA). Для всех оплачиваемых уровней соглашения об уровне обслуживания вступают в силу, если для службы обеспечена достаточная избыточность. Для предоставления соглашения об уровне обслуживания, предусматривающего создание запросов (операции чтения), требуется не менее двух реплик. Для предоставления соглашения об уровне обслуживания, предусматривающего создание запросов и индексирование (чтение и запись), требуется не менее трех реплик. Количество секций не влияет на соглашения об уровне обслуживания.
Советы по планированию емкости
Разрешите метрикам сформироваться по запросам и соберите данные по шаблонам использования (запросы в рабочее время, индексирование в часы наименьшей нагрузки). Используйте эти данные для принятия решений о подготовке службы. Хотя это не всегда удобно, вы можете динамически настраивать секции и ресурсы для размещения запланированных изменений в объемах запросов или незапланированных, но устойчивых изменений, если это оправдано.
Помните, что единственным минусом недостаточной подготовки является то, что вам, возможно, придется удалить службу, если фактические требования превысят вашу оценку. Чтобы избежать сбоев в работе службы, вы должны создать новую службу на более высоком уровне и запустить ее параллельно, пока все приложения и запросы не будут направлены на новую конечную точку.
Когда следует расширять емкость
Для службы поиска изначально выделяется минимальный уровень ресурсов, состоящий из одного раздела и одной реплики. Выбранный ценовой уровень определяет размер и скорость секции, и каждый уровень оптимизирован по набору характеристик, соответствующих различным сценариям. При выборе более высокого уровня может потребоваться меньше секций, чем для уровня S1. Один из вопросов, на которые нужно ответить при самостоятельном тестировании, — удается ли вам добиться повышения производительности с более дорогой секцией большего размера по сравнению с двумя более дешевыми секциями в службе более низкого уровня.
Одна служба должна иметь достаточно ресурсов для обработки всех рабочих нагрузок (индексирования и запросов). Ни одна рабочая нагрузка не выполняется в фоновом режиме. Можно запланировать индексирование в течение времени, когда запросы, естественно, реже, но служба не будет определять приоритеты одной задачи по сравнению с другой. Кроме того, определенный объем избыточности повышает производительность запросов при внутреннем обновлении служб или узлов.
Вот еще несколько факторов, от которых зависит целесообразность расширения емкости.
- Обеспечение высокого уровня доступности в соответствии с соглашением об уровне обслуживания
- Повышение частоты ошибок HTTP 503.
- Предполагаемое увеличение объемов запросов
Как правило, приложениям поиска требуется больше реплик, чем секций, особенно если служба в основном обрабатывает рабочие нагрузки запросов. Реплика — это копия вашего индекса, позволяющая службе балансировать нагрузку по запросам, распределяя их между несколькими копиями. Все подсистемы балансировки нагрузки и реплика индексов управляются поиском ИИ Azure, и вы можете изменить количество реплика, выделенных для службы в любое время. Можно выделить до 12 реплик для службы поиска уровня "Стандартный" и до 3 реплик для службы поиска уровня "Базовый". Для выделения реплики можно использовать портал Azure либо одно из программных средств.
Приложениям поиска, которым требуется обновления данных в режиме, близком к реальному времени, понадобится пропорционально больше секций, чем реплик. При добавлении секций операции чтения-записи распределяются среди большего количества вычислительных ресурсов. Оно также обеспечивает больше дискового пространства для хранения дополнительных индексов и документов.
Наконец, запрос к большому индексу выполняется дольше. Поэтому может оказаться, что каждое добавочное увеличение числа секций потребует меньшего, но пропорционального увеличения числа реплик. Сложность запросов и их объем обусловливают скорость выполнения запросов.
Примечание.
Добавление реплик или секций увеличивает затраты на эксплуатацию службы и может вести к незначительным колебаниям в порядке выдаваемых результатов. Не забудьте воспользоваться калькулятором цен, который позволяет понять, как добавление узлов влияет на затраты. Диаграмма ниже позволит вам сориентироваться в количестве единиц поиска, необходимых для той или иной конфигурации. Дополнительные сведения о том, как дополнительные реплики влияют на обработку запросов, см. в статье Упорядочение результатов.
Добавление и удаление реплик и секций
Войдите на портал Azure и выберите службу поиска.
В разделе Параметрыоткройте страницу Масштаб, чтобы изменить число реплик и секций.
На снимке экрана ниже показана служба категории "Базовый стандартный", подготовленная с одной репликой и секцией. В формуле внизу показано, сколько единиц поиска используется (1). Если бы цена за единицу составляла 1000 рублей (это произвольное, а не реальное значение), ежемесячная стоимость эксплуатации этой службы составляла бы в среднем 1000 рублей.
С помощью ползунка увеличивайте и уменьшайте число секций. Выберите Сохранить.
В этом примере добавляются вторая реплика и секция. Обратите внимание на количество единиц поиска; Теперь это четыре, так как формула выставления счетов реплика умножена на секции (2 x 2). Удвоение емкости ведет к увеличению затрат на службу более чем вдвое. Если бы цена за единицу поиска составляла 1000 рублей, новый ежемесячный счет теперь составлял бы 4000 рублей.
Текущую стоимость на единицу на каждом ценовом уровне см. на странице цен.
После сохранения проверьте уведомления на случай, если от вас требуются дополнительные действия.
Для изменения емкости может потребоваться от 15 минут до нескольких часов. После начала процесса невозможно отменить мониторинг в режиме реального времени для реплика и корректировки секций. Однако в процессе применения изменений отображается следующее сообщение.
Примечание.
После подготовки службы перевести ее на более высокий ценовой уровень невозможно. Вам нужно будет создать службу поиска на новом уровне и перезагрузить индексы. Дополнительные сведения о подготовке служб см. в статье "Создание служба ИИ Azure" на портале.
Как обрабатываются запросы на масштабирование
При получении запроса на масштабирование служба поиска делает следующее:
- Проверяет, допустимый ли запрос.
- Запускает резервное копирование данных и системных сведений.
- Проверяет, находится ли служба в состоянии подготовки (в настоящее время добавление или удаление реплик или секций).
- Начинает подготовку.
Масштабирование службы может занять всего 15 минут или более часа, в зависимости от размера службы и области запроса. Резервное копирование может занять несколько минут в зависимости от объема данных и количества секций и реплик.
Приведенные выше шаги не полностью последовательны. Например, система начинает подготовку, когда она может запустить ее безопасно, а это может быть во время завершения резервного копирования.
Ошибки при масштабировании
Сообщение об ошибке "Операции обновления службы на данный момент не разрешены, так как мы обрабатываем предыдущий запрос" вызвано повтором запроса, чтобы уменьшить или увеличить масштаб, когда служба уже обрабатывает предыдущий запрос.
Чтобы устранить эту ошибку, проверьте состояние службы, чтобы проверить состояние подготовки:
- Для получения состояния службы используйте REST API управления, Azure PowerShell или Azure CLI.
- Вызовите службу get (REST) или эквивалентную для PowerShell или ИНТЕРФЕЙСА командной строки.
- Проверьте ответ на наличие состояния provisioningState: подготовка
Если состояние — "Подготовка", дождитесь завершения запроса. Перед попыткой выполнения другого запроса состояние должно иметь значение "Успешно" или "Ошибка". Для резервного копирования нет состояния. Резервное копирование является внутренней операцией, и маловероятно, что оно не повлияет на перерывы в выполнении упражнения масштабирования.
Если служба поиска, как представляется, остановилась в состоянии подготовки, проверка для потерянных индексов, которые недоступны для использования, с нулевыми томами запросов и без обновлений индекса. Неиспользуемый индекс может блокировать изменения емкости службы. В частности, найдите индексы, зашифрованные с помощью CMK, ключи которых больше не допустимы. Необходимо удалить индекс или восстановить ключи, чтобы вернуть индекс в режим "в сети" и разблокировать операцию масштабирования.
сочетания разделов и реплик
В службах поиска, созданных до 3 апреля 2024 г., базовые службы могут иметь ровно одну секцию и до трех реплика для максимального ограничения трех единиц SUS. Единственным ресурсом, который можно изменять, являются реплики.
В службах поиска, созданных после 3 апреля 2024 г. в поддерживаемых регионах, базовые могут содержать до трех разделов и трех реплика. Максимальное ограничение su составляет девять для поддержки полного дополнения секций и реплика.
Для служб поиска на любом оплачиваемом уровне независимо от даты создания требуется не менее двух реплика для обеспечения высокой доступности запросов.
Во всех службах поиска уровня "Стандартный" и "Оптимизировано для операций в хранилище" можно использовать указанные ниже сочетания реплик и секций с ограничением в 36 единиц поиска, установленным для этих уровней.
| 1 секция | 2 секции | 3 секции | 4 секции | 6 секций | 12 секций | |
|---|---|---|---|---|---|---|
| 1 реплика | 1 SU | 2 ЕП | 3 ЕП | 4 ЕП | 6 ЕП | 12 ЕП |
| 2 реплики | 2 ЕП | 4 ЕП | 6 ЕП | 8 ЕП | 12 ЕП | 24 ЕП |
| 3 реплики | 3 ЕП | 6 ЕП | 9 ЕП | 12 ЕП | 18 ЕП | 36 ЕП |
| 4 реплики | 4 ЕП | 8 ЕП | 12 ЕП | 16 ЕП | 24 ЕП | Н/П |
| 5 реплик | 5 ЕП | 10 ЕП | 15 ЕП | 20 ЕП | 30 ЕП | Н/П |
| 6 реплик | 6 ЕП | 12 ЕП | 18 ЕП | 24 ЕП | 36 ЕП | Н/П |
| 12 реплик | 12 ЕП | 24 ЕП | 36 ЕП | Неприменимо | Н/Д | Неприменимо |
Подробные сведения о единицах поиска, ценах и объемах приведены на веб-сайте Azure. Дополнительные сведения см. на странице с ценами.
Примечание.
Количество реплик и секций должно быть делителем 12 (а именно 1, 2, 3, 4, 6, 12). Поиск по искусственному интеллекту Azure предварительно делит каждый индекс на 12 сегментов, чтобы его можно было распределять по равным частям по всем секциям. Например, если в вашей службе есть три секции и вы создаете индекс, то каждая секция будет содержать по четыре сегмента индекса. Как поиск azure AI сегментирует индекс является подробным описанием реализации, при условии изменения в будущих выпусках. Несмотря на то, что сегодня это число 12, вам не следует полагаться на то, что в будущем оно не изменится.