Estimar e gerir a capacidade de um serviço de pesquisa
No Azure AI Search, a capacidade é baseada em réplicas e partições que podem ser dimensionadas para sua carga de trabalho. As réplicas são cópias do motor de pesquisa. As divisórias são unidades de armazenamento. Cada novo serviço de pesquisa começa com um cada, mas você pode adicionar ou remover réplicas e partições independentemente para acomodar cargas de trabalho flutuantes. Adicionar capacidade aumenta o custo de execução de um serviço de pesquisa.
As características físicas das réplicas e partições, como velocidade de processamento e E/S do disco, variam de acordo com a camada de serviço. Em um serviço de pesquisa padrão, as réplicas e partições são mais rápidas e maiores do que as de um serviço básico.
A mudança de capacidade não é instantânea. Pode levar até uma hora para comissionar ou desativar partições, especialmente em serviços com grandes quantidades de dados.
Ao dimensionar um serviço de pesquisa, você pode escolher entre as seguintes ferramentas e abordagens:
Conceitos: unidades de pesquisa, réplicas, partições, fragmentos
A capacidade é expressa em unidades de pesquisa que podem ser alocadas em combinações de partições e réplicas, usando um mecanismo de fragmentação subjacente para suportar configurações flexíveis:
| Conceito | Definição |
|---|---|
| Unidade de pesquisa | Um único incremento da capacidade total disponível (36 unidades). É também a unidade de faturação de um serviço Azure AI Search. É necessário um mínimo de uma unidade para executar o serviço. |
| Réplica | Instâncias do serviço de pesquisa, usadas principalmente para operações de consulta de balanceamento de carga. Cada réplica hospeda uma cópia de um índice. Se você alocar três réplicas, terá três cópias de um índice disponíveis para atender às solicitações de consulta. |
| Partição | Armazenamento físico e E/S para operações de leitura/gravação (por exemplo, ao reconstruir ou atualizar um índice). Cada partição tem uma fatia do índice total. Se você alocar três partições, seu índice será dividido em terços. |
| Fragmento | Um pedaço de um índice. O Azure AI Search divide cada índice em fragmentos para tornar o processo de adição de partições mais rápido (movendo fragmentos para novas unidades de pesquisa). |
O diagrama a seguir mostra a relação entre réplicas, partições, fragmentos e unidades de pesquisa. Ele mostra um exemplo de como um único índice é estendido em quatro unidades de pesquisa em um serviço com duas réplicas e duas partições. Cada uma das quatro unidades de pesquisa armazena apenas metade dos fragmentos do índice. As unidades de pesquisa na coluna da esquerda armazenam a primeira metade dos fragmentos, compreendendo a primeira partição, enquanto as da coluna da direita armazenam a segunda metade dos fragmentos, compreendendo a segunda partição. Como há duas réplicas, há duas cópias de cada fragmento de índice. As unidades de pesquisa na linha superior armazenam uma cópia, compreendendo a primeira réplica, enquanto as da linha inferior armazenam outra cópia, compreendendo a segunda réplica.
O diagrama acima é apenas um exemplo. Muitas combinações de partições e réplicas são possíveis, até um máximo de 36 unidades de pesquisa totais.
Na Pesquisa de IA do Azure, o gerenciamento de fragmentos é um detalhe de implementação e não configurável, mas saber que um índice é fragmentado ajuda a entender as anomalias ocasionais na classificação e nos comportamentos de preenchimento automático:
Anomalias de classificação: as pontuações de pesquisa são calculadas primeiro no nível de estilhaço e, em seguida, agregadas em um único conjunto de resultados. Dependendo das características do conteúdo de estilhaços, as partidas de um fragmento podem ser classificadas mais alto do que as partidas de outro. Se você notar classificações contraintuitivas nos resultados de pesquisa, é mais provável que seja devido aos efeitos da fragmentação, especialmente se os índices forem pequenos. Você pode evitar essas anomalias de classificação optando por calcular pontuações globalmente em todo o índice, mas isso incorrerá em uma penalidade de desempenho.
Anomalias de preenchimento automático: as consultas de preenchimento automático, em que as correspondências são feitas nos primeiros caracteres de um termo parcialmente inserido, aceitam um parâmetro difuso que perdoa pequenos desvios na ortografia. Para preenchimento automático, a correspondência difusa é restrita a termos dentro do fragmento atual. Por exemplo, se um fragmento contiver "Microsoft" e um termo parcial de "micro" for inserido, o mecanismo de pesquisa corresponderá a "Microsoft" nesse fragmento, mas não em outros fragmentos que contêm as partes restantes do índice.
Objetivos de estimativa
O planejamento de capacidade deve incluir limites de objeto (por exemplo, o número máximo de índices permitidos em um serviço) e limites de armazenamento. A camada de serviço determina os limites de objeto e armazenamento. Qualquer que seja o limite atingido primeiro é o limite efetivo.
As contagens de índices e outros objetos são normalmente ditadas por requisitos de negócios e engenharia. Por exemplo, você pode ter várias versões do mesmo índice para desenvolvimento, teste e produção ativos.
As necessidades de armazenamento são determinadas pelo tamanho dos índices que você espera criar. Não há heurísticas ou generalidades sólidas que ajudem nas estimativas. A única maneira de determinar o tamanho de um índice é construir um. Seu tamanho será baseado em dados importados, análise de texto e configuração de índice, como se você habilitar sugestões, filtragem e classificação.
Para pesquisa de texto completo, a estrutura de dados primária é uma estrutura de índice invertido, que tem características diferentes dos dados de origem. Para um índice invertido, o tamanho e a complexidade são determinados pelo conteúdo, não necessariamente pela quantidade de dados que você alimenta nele. Uma fonte de dados grande com alta redundância pode resultar em um índice menor do que um conjunto de dados menor que contém conteúdo altamente variável. Portanto, raramente é possível inferir o tamanho do índice com base no tamanho do conjunto de dados original.
Os atributos no índice, como a habilitação de filtros e a classificação, afetam os requisitos de armazenamento. O uso de sugestões também tem implicações de armazenamento. Para obter mais informações, consulte Atributos e tamanho do índice.
Nota
Embora estimar as necessidades futuras de índices e armazenamento possa parecer adivinhação, vale a pena fazê-lo. Se a capacidade de um nível for muito baixa, você precisará provisionar um novo serviço em um nível mais alto e, em seguida , recarregar seus índices. Não há atualização in-loco de um serviço de uma camada para outra.
Estimativa com o nível Gratuito
Uma abordagem para estimar a capacidade é começar com o nível Gratuito. Lembre-se que o serviço gratuito oferece até três índices, 50 MB de armazenamento e 2 minutos de tempo de indexação. Pode ser desafiador estimar um tamanho de índice projetado com essas restrições, mas estas são as etapas:
Crie um serviço gratuito.
Prepare um conjunto de dados pequeno e representativo.
Crie um índice e carregue seus dados. Se o conjunto de dados puder ser hospedado em uma fonte de dados do Azure com suporte de indexadores, você poderá usar o assistente Importar dados no portal para criar e carregar o índice. Caso contrário, você pode usar APIs REST para criar o índice e enviar os dados por push. O modelo de push requer que os dados estejam na forma de documentos JSON, onde os campos no documento correspondem aos campos no índice.
Colete informações sobre o índice, como tamanho. Recursos e atributos afetam o armazenamento. Por exemplo, adicionar sugestões (consultas de pesquisa conforme o tipo) aumentará os requisitos de armazenamento.
Usando o mesmo conjunto de dados, você pode tentar criar várias versões de um índice, com atributos diferentes em cada campo, para ver como os requisitos de armazenamento variam. Para obter mais informações, consulte "Implicações de armazenamento" em Criar um índice básico.
Com uma estimativa aproximada em mãos, você pode dobrar esse valor para o orçamento para dois índices (desenvolvimento e produção) e, em seguida, escolher sua camada de acordo.
Estimar com um nível faturável
Recursos dedicados podem acomodar maiores tempos de amostragem e processamento para estimativas mais realistas de quantidade, tamanho e volumes de consulta de índice durante o desenvolvimento. Alguns clientes entram diretamente com um nível faturável e, em seguida, reavaliam à medida que o projeto de desenvolvimento amadurece.
Analise os limites de serviço em cada camada para determinar se as camadas inferiores podem suportar o número de índices de que você precisa. Nas camadas Basic, S1 e S2, os limites de índice são 15, 50 e 200, respectivamente. A camada de armazenamento otimizado tem um limite de 10 índices porque foi projetada para oferecer suporte a um número baixo de índices muito grandes.
Crie um serviço em um nível faturável:
- Comece baixo, em Basic ou S1, se não tiver certeza sobre a carga projetada.
- Comece alto, em S2 ou mesmo S3, se o teste incluir indexação em grande escala e cargas de consulta.
- Comece com Armazenamento otimizado, em L1 ou L2, se você estiver indexando uma grande quantidade de dados e a carga de consulta for relativamente baixa, como em um aplicativo de negócios interno.
Crie um índice inicial para determinar como os dados de origem se traduzem em um índice. Esta é a única maneira de estimar o tamanho do índice.
Monitore o armazenamento, os limites de serviço, o volume de consultas e a latência no portal. O portal mostra consultas por segundo, consultas limitadas e latência de pesquisa. Todos esses valores podem ajudá-lo a decidir se você selecionou a camada correta.
Adicione réplicas para alta disponibilidade ou para reduzir o desempenho lento da consulta.
Não há diretrizes sobre quantas réplicas são necessárias para acomodar cargas de consulta. O desempenho da consulta depende da complexidade da consulta e das cargas de trabalho concorrentes. Embora a adição de réplicas resulte claramente em melhor desempenho, o resultado não é estritamente linear: adicionar três réplicas não garante uma taxa de transferência tripla. Para obter orientação sobre como estimar o QPS para sua solução, consulte Analisar desempenhoe monitorar consultas.
Nota
Os requisitos de armazenamento podem ser inflados se você incluir dados que nunca serão pesquisados. Idealmente, os documentos contêm apenas os dados de que necessita para a experiência de pesquisa. Os dados binários não podem ser pesquisados e devem ser armazenados separadamente (talvez em uma tabela ou armazenamento de blob do Azure). Um campo deve ser adicionado ao índice para conter uma referência de URL para os dados externos. O tamanho máximo de um documento de pesquisa individual é de 16 MB (ou menos se estiver a carregar vários documentos em massa num pedido). Para obter mais informações, consulte Limites de serviço no Azure AI Search.
Considerações sobre o volume de consulta
Consultas por segundo (QPS) é uma métrica importante durante o ajuste de desempenho, mas para o planejamento de capacidade, torna-se uma consideração apenas se você esperar um alto volume de consultas no início.
As camadas Standard podem fornecer um equilíbrio de réplicas e partições. Você pode aumentar o turnaround de consultas adicionando réplicas para balanceamento de carga ou adicionando partições para processamento paralelo. Em seguida, você pode ajustar o desempenho depois que o serviço for provisionado.
Se você espera altos volumes de consulta sustentados desde o início, deve considerar camadas Standard mais altas, apoiadas por hardware mais poderoso. Em seguida, você pode colocar partições e réplicas offline ou até mesmo alternar para um serviço de camada inferior, se esses volumes de consulta não ocorrerem. Para obter mais informações sobre como calcular a taxa de transferência da consulta, consulte Monitorar consultas.
Os níveis otimizados para armazenamento são úteis para grandes cargas de trabalho de dados, oferecendo suporte a um armazenamento de índice mais geral disponível para quando os requisitos de latência de consulta são menos importantes. Você ainda deve usar réplicas adicionais para balanceamento de carga e partições adicionais para processamento paralelo. Em seguida, você pode ajustar o desempenho depois que o serviço for provisionado.
Contratos de nível de serviço
Os recursos de nível gratuito e visualização não são cobertos por SLAs (contratos de nível de serviço). Para todos os níveis faturáveis, os SLAs entram em vigor quando você provisiona redundância suficiente para seu serviço. Você precisa ter duas ou mais réplicas para consultar (ler) SLAs. Você precisa ter três ou mais réplicas para SLAs de consulta e indexação (leitura-gravação). O número de partições não afeta os SLAs.
Dicas para planejamento de capacidade
Permita que as métricas se baseiem em consultas e coletem dados em torno de padrões de uso (consultas durante o horário comercial, indexação fora do horário de pico). Use esses dados para informar decisões de provisionamento de serviços. Embora não seja prático em uma cadência horária ou diária, você pode ajustar dinamicamente partições e recursos para acomodar alterações planejadas nos volumes de consulta. Você também pode acomodar alterações não planejadas, mas sustentadas, se os níveis permanecerem por tempo suficiente para justificar a tomada de medidas.
Lembre-se de que a única desvantagem do subprovisionamento é que você pode ter que derrubar um serviço se os requisitos reais forem maiores do que suas previsões. Para evitar a interrupção do serviço, você criaria um novo serviço em uma camada mais alta e o executaria lado a lado até que todos os aplicativos e solicitações tivessem como alvo o novo ponto de extremidade.
Quando adicionar capacidade
Inicialmente, um serviço recebe um nível mínimo de recursos que consistem em uma partição e uma réplica. A camada escolhida determina o tamanho e a velocidade da partição, e cada camada é otimizada em torno de um conjunto de características que se ajustam a vários cenários. Se você escolher uma camada mais avançada, talvez precise de menos partições do que se optar pelo S1. Uma das perguntas que você precisará responder por meio de testes autodirigidos é se uma partição maior e mais cara produz melhor desempenho do que duas partições mais baratas em um serviço provisionado em um nível mais baixo.
Um único serviço deve ter recursos suficientes para lidar com todas as cargas de trabalho (indexação e consultas). Nenhuma carga de trabalho é executada em segundo plano. Você pode agendar a indexação para momentos em que as solicitações de consulta são naturalmente menos frequentes, mas o serviço não priorizará uma tarefa em detrimento de outra. Além disso, uma certa quantidade de redundância suaviza o desempenho da consulta quando os serviços ou nós são atualizados internamente.
Algumas diretrizes para determinar se a capacidade deve ser adicionada incluem:
- Atendendo aos critérios de alta disponibilidade para o contrato de nível de serviço
- A frequência de erros HTTP 503 está aumentando
- São esperados grandes volumes de consulta
Como regra geral, os aplicativos de pesquisa tendem a precisar de mais réplicas do que partições, especialmente quando as operações de serviço são tendenciosas para cargas de trabalho de consulta. Cada réplica é uma cópia do seu índice, permitindo que o serviço balanceie a carga de solicitações em relação a várias cópias. Todo o balanceamento de carga e replicação de um índice é gerenciado pelo Azure AI Search e você pode alterar o número de réplicas alocadas para seu serviço a qualquer momento. Você pode alocar até 12 réplicas em um serviço de pesquisa padrão e 3 réplicas em um serviço de pesquisa Básico. A alocação de réplicas pode ser feita a partir do portal do Azure ou de uma das opções programáticas.
Os aplicativos de pesquisa que exigem atualização de dados quase em tempo real precisarão proporcionalmente de mais partições do que réplicas. Adicionar partições distribui operações de leitura/gravação por um número maior de recursos de computação. Ele também oferece mais espaço em disco para armazenar índices e documentos adicionais.
Finalmente, índices maiores levam mais tempo para consultar. Como tal, você pode achar que cada aumento incremental em partições requer um aumento menor, mas proporcional, em réplicas. A complexidade das consultas e do volume de consultas influenciará a rapidez com que a execução da consulta será transformada.
Nota
Adicionar mais réplicas ou partições aumenta o custo de execução do serviço e pode introduzir pequenas variações na forma como os resultados são ordenados. Certifique-se de verificar a calculadora de preços para entender as implicações de faturamento da adição de mais nós. O gráfico abaixo pode ajudá-lo a fazer referência cruzada ao número de unidades de pesquisa necessárias para uma configuração específica. Para obter mais informações sobre como réplicas adicionais afetam o processamento de consultas, consulte Ordenando resultados.
Adicionar ou reduzir réplicas e partições
Entre no portal do Azure e selecione o serviço de pesquisa.
Em Configurações, abra a página Escala para modificar réplicas e partições.
A captura de tela a seguir mostra um padrão básico provisionado com uma réplica e uma partição. A fórmula na parte inferior indica quantas unidades de pesquisa estão a ser utilizadas (1). Se o preço unitário fosse de US $ 100 (não um preço real), o custo mensal de execução deste serviço seria de US $ 100 em média.
Use o controle deslizante para aumentar ou diminuir o número de partições. Selecione Guardar.
Este exemplo adiciona uma segunda réplica e uma partição. Observe a contagem de unidades de pesquisa; agora são quatro porque a fórmula de faturamento é replicações multiplicadas por partições (2 x 2). A duplicação da capacidade mais do que duplica o custo de funcionamento do serviço. Se o custo unitário de pesquisa fosse de US $ 100, a nova conta mensal agora seria de US $ 400.
Para obter os custos unitários atuais de cada nível, visite a página Preços.
Depois de salvar, você pode verificar as notificações para confirmar que a ação foi bem-sucedida.
As alterações na capacidade podem levar de 15 minutos a várias horas para serem concluídas. Não é possível cancelar depois que o processo for iniciado e não houver monitoramento em tempo real para ajustes de réplica e partição. No entanto, a seguinte mensagem permanece visível enquanto as alterações estão em curso.
Nota
Depois que um serviço é provisionado, ele não pode ser atualizado para uma camada superior. Você deve criar um serviço de pesquisa na nova camada e recarregar seus índices. Consulte Criar um serviço Azure AI Search no portal para obter ajuda com o provisionamento de serviços.
Como as solicitações de escala são tratadas
Após receção de um pedido de escala, o serviço de pesquisa:
- Verifica se a solicitação é válida.
- Inicia o backup de dados e informações do sistema.
- Verifica se o serviço já está em um estado de provisionamento (atualmente adicionando ou eliminando réplicas ou partições).
- Inicia o provisionamento.
O dimensionamento de um serviço pode levar apenas 15 minutos ou bem mais de uma hora, dependendo do tamanho do serviço e do escopo da solicitação. O backup pode levar vários minutos, dependendo da quantidade de dados e do número de partições e réplicas.
As etapas acima não são totalmente consecutivas. Por exemplo, o sistema inicia o provisionamento quando pode fazê-lo com segurança, o que pode ocorrer enquanto o backup está acabando.
Erros durante o dimensionamento
A mensagem de erro "As operações de atualização de serviço não são permitidas neste momento porque estamos processando uma solicitação anterior" é causada pela repetição de uma solicitação para reduzir ou aumentar quando o serviço já está processando uma solicitação anterior.
Resolva esse erro verificando o status do serviço para verificar o status do provisionamento:
- Use a API REST de gerenciamento, o Azure PowerShell ou a CLI do Azure para obter o status do serviço.
- Chame Get Service (REST) ou equivalente para o PowerShell ou a CLI.
- Verifique a resposta para "provisioningState": "provisioning"
Se o status for "Provisionamento", aguarde a conclusão da solicitação. O status deve ser "Bem-sucedido" ou "Falhado" antes que outra solicitação seja tentada. Não há status para backup. O backup é uma operação interna e é improvável que seja um fator em qualquer interrupção de um exercício de escala.
Se o serviço de pesquisa parecer estar parado em um estado de provisionamento, verifique se há índices órfãos inutilizáveis, com zero volumes de consulta e sem atualizações de índice. Um índice inutilizável pode bloquear alterações na capacidade de serviço. Em particular, procure por índices que são criptografados por CMK, cujas chaves não são mais válidas. Você deve excluir o índice ou restaurar as chaves para colocá-lo online novamente e desbloquear sua operação de escala.
Combinações de partição e réplica
Em serviços de pesquisa criados antes de 3 de abril de 2024: Basic pode ter exatamente uma partição e até três réplicas, para um limite máximo de três SUs. O único recurso ajustável são as réplicas.
Nos serviços de pesquisa criados após 3 de abril de 2024 em regiões suportadas: o Basic pode ter até três partições e três réplicas. O limite máximo de SU é de nove para suportar um complemento completo de partições e réplicas.
Para serviços de pesquisa em qualquer nível faturável, independentemente da data de criação, você precisa de um mínimo de duas réplicas para alta disponibilidade em consultas.
Todos os serviços de pesquisa Standard e Storage Optimized podem assumir as seguintes combinações de réplicas e partições, sujeitas ao limite de 36-SU permitido para esses níveis.
| 1 partição | 2 divisórias | 3 divisórias | 4 divisórias | 6 divisórias | 12 divisórias | |
|---|---|---|---|---|---|---|
| 1 réplica | 1 SU | 2 SU | 3 SU | 4 SU | 6 SU | 12 SU |
| 2 réplicas | 2 SU | 4 SU | 6 SU | 8 SU | 12 SU | 24 SU |
| 3 réplicas | 3 SU | 6 SU | 9 SU | 12 SU | 18 SU | 36 SU |
| 4 réplicas | 4 SU | 8 SU | 12 SU | 16 SU | 24 SU | N/A |
| 5 réplicas | 5 SU | 10 SU | 15 SU | 20 SU | 30 SU | N/A |
| 6 réplicas | 6 SU | 12 SU | 18 SU | 24 SU | 36 SU | N/A |
| 12 réplicas | 12 SU | 24 SU | 36 SU | N/A | N/D | N/A |
SUs, preços e capacidade são explicados em detalhes no site do Azure. Para obter mais informações, consulte Detalhes de preços.
Nota
O número de réplicas e partições divide-se uniformemente em 12 (especificamente, 1, 2, 3, 4, 6, 12). O Azure AI Search pré-divide cada índice em 12 fragmentos para que possa ser distribuído em partes iguais em todas as partições. Por exemplo, se o serviço tiver três partições e você criar um índice, cada partição conterá quatro fragmentos do índice. Como o Azure AI Search fragmenta um índice é um detalhe de implementação, sujeito a alterações em versões futuras. Embora o número seja 12 hoje, você não deve esperar que esse número seja sempre 12 no futuro.