Estimar e gerenciar a capacidade de um serviço de pesquisa
Na IA do Azure 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 mecanismo de pesquisa. As partições 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 de réplicas e partições, como velocidade de processamento e E/S de 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 alteração de capacidade não é instantânea. Pode levar até uma hora para comissionar ou descomissionar partições, especialmente em serviços com grandes quantidades de dados.
Ao escalar 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 dar suporte a configurações flexíveis:
| Conceito | Definição |
|---|---|
| Unidade de pesquisa | Um incremento da capacidade total disponível (36 unidades). Isso também é a unidade de cobrança de um serviço de IA do Azure 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 equilibrar a carga das operações de consulta. 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 recompilar ou atualizar um índice). Cada partição tem uma fatia do índice total. Se você alocar três partições, o índice será dividido em terços. |
| Fragmento | Uma parte de um índice. A IA do Azure 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 o relacionamento entre as réplicas, partições, fragmentos e unidades de pesquisa. Ele mostra um exemplo de como um í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 à esquerda armazenam a primeira metade dos fragmentos, composta pela primeira partição, enquanto aquelas na coluna à direita armazenam a segunda metade dos fragmentos, composta pela 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, composta pela primeira réplica, enquanto as unidades na linha inferior armazenam outra cópia, composta pela 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 no total.
Na IA do Azure Search, 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 nos comportamentos de preenchimento automático e classificação:
Classificação de anomalias: as pontuações de pesquisa são computadas primeiro no nível do fragmento e depois agregadas em um conjunto de resultados. Dependendo das características do conteúdo do fragmento, as correspondências de um fragmento podem ter uma classificação maior do que as correspondências em outro. Se você observar classificações contra-intuitivas nos resultados da pesquisa, isso provavelmente ocorre devido aos efeitos da fragmentação, especialmente se os índices forem baixos. Você pode evitar essas anomalias de classificação escolhendo computar 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, nas quais as correspondências são feitas nos primeiros caracteres de um termo parcialmente inserido, aceitam um parâmetro difuso que ignora pequenos erros de 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.
Destinos 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 objetos e de armazenamento. O limite que for atingido primeiro é o limite efetivo.
As contagens de índices e de outros objetos geralmente são ditadas por requisitos empresariais e de 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á nenhuma heurística sólida nem generalizações que ajudem na obtenção de estimativas. A única maneira de determinar o tamanho de um índice é criando um. O tamanho será baseado em dados importados, na análise de texto e na configuração de índice, por exemplo, se você deve habilitar sugestores, 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. Em um índice invertido, o tamanho e a complexidade são determinados pelo conteúdo, não necessariamente pela quantidade de dados que são inseridos 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 um conteúdo altamente variável. Portanto, é raramente possível inferir o tamanho de índice com base no tamanho do conjunto de dados original.
Os atributos no índice, como habilitar filtros e classificação, afetam os requisitos de armazenamento. O uso de sugestores também tem implicações de armazenamento. Para obter mais informações, confira Atributos e tamanho do índice.
Observação
Embora a estimativa das necessidades futuras de armazenamento e de índices possa parecer adivinhação, vale a pena fazê-la. Se a capacidade de uma camada for muito baixa, você precisará provisionar um novo serviço em uma camada superior e recarregar os índices. Não há nenhuma atualização in-loco de um serviço de uma camada para outra.
Estimar com a Camada gratuita
Uma abordagem para calcular a capacidade é iniciar com a camada Livre. Lembre-se de que o serviço Gratuito oferece até três índices, 50 MB de armazenamento e um tempo de indexação de dois minutos. Pode ser desafiador estimar um tamanho de índice projetado com essas restrições, mas siga as etapas abaixo:
Prepare um conjunto de dados pequeno e representativo.
Crie um índice e carregue os 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 de importação de dados no portal para criar e carregar o índice. Caso contrário, você pode usar a API REST para criar o índice e enviar os dados. O modelo de push requer que os dados estejam na forma de documentos JSON, na qual os campos no documento correspondem aos campos no índice.
Colete informações sobre o índice, como o tamanho. Recursos e atributos afetam o armazenamento. Por exemplo, a adição de sugestores (consultas do tipo "pesquisar ao digitar") 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, confira "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 de dois índices (desenvolvimento e produção) e então escolher a camada adequadamente.
Estimar com uma camada faturável
Os recursos dedicados podem acomodar amostragem e tempos de processamento maiores para obter estimativas mais realistas da quantidade do índice, tamanho e volumes de consulta durante o desenvolvimento. Alguns clientes começam com uma camada faturável e reavaliam à medida que o projeto de desenvolvimento amadurece.
Examine os limites de serviço em cada camada para determinar se as camadas mais baixas podem dar suporte ao número de índices que você precisa. Nas camadas Básica, S1 e S2, os limites de índice são 15, 50 e 200, respectivamente. A camada do tipo Otimizado para Armazenamento tem um limite de dez índices porque ela foi projetada para dar suporte a um pequeno número de índices muito grandes.
Criar um serviço em uma camada faturável:
- Comece em uma camada baixa, como Básico ou S1, se você não tiver certeza da carga projetada.
- Comece em uma camada alta, na S2 ou até mesmo S3, se o teste incluir cargas de consulta e indexação de grande escala.
- Comece com Otimizado para Armazenamento, em L1 ou L2, se você estiver indexando uma grande quantidade de dados e a carga de consulta for relativamente baixa, assim como em um aplicativo de negócios interno.
Criar um índice inicial para determinar como a fonte de dados traduz para um índice. Essa é a única maneira de estimar o tamanho do índice.
Monitorar armazenamento, limites de serviço, volume de consulta e latência no portal. O portal mostra as consultas por segundo, consultas limitadas e latência de pesquisa. Todos esses valores podem ajudar você a decidir se selecionou a camada certa.
Adicione réplicas para alta disponibilidade ou mitigação de desempenho lento de consulta.
Não há diretrizes sobre quantas réplicas são necessárias para acomodar as 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 definitivamente melhore o desempenho, o resultado não é estritamente linear: a adição de três réplicas não garante o triplo da taxa de transferência. Para obter diretrizes sobre como estimar a QPS da sua solução, confira Análise de desempenhoe Monitorar consultas.
Observação
Os requisitos de armazenamento poderão aumentar se você incluir dados que nunca serão pesquisados. Idealmente, os documentos contêm apenas os dados necessários para a experiência de pesquisa. Os dados binários não são pesquisáveis e devem ser armazenados separadamente (talvez em um armazenamento de blobs ou de tabelas do Azure). Em seguida, um campo deve ser adicionado no índice para manter uma referência de URL aos dados externos. O tamanho máximo de um documento de pesquisa individual é de 16 MB (ou menos, se você estiver carregando em massa vários documentos em uma solicitação). Para obter mais informações, confira Limites de serviço na IA do Azure Search.
Considerações sobre volume de consultas
As consultas por segundo (QPS) são uma métrica importante durante o ajuste de desempenho, mas, para o planejamento da capacidade, ela se torna uma consideração somente se você espera um volume de consulta alto no início.
As camadas Standard podem fornecer um equilíbrio entre réplicas e partições. Você pode aumentar o retorno da consulta adicionando réplicas para balanceamento de carga ou partições para processamento paralelo. Em seguida, você pode ajustar o desempenho depois que o serviço é fornecido.
Se você espera altos volumes de consulta contínuas desde o início, considere usar camadas Standard maiores, que têm o suporte de um hardware mais potente. Você poderá colocar as partições e réplicas offline ou até mesmo alternar para um serviço de camada inferior, caso esses volumes de consulta não ocorram. Para obter mais informações sobre como calcular a taxa de transferência de consulta, consulte Monitorar consultas.
As camadas do tipo Otimizado para Armazenamento são úteis para cargas de trabalho de dados grandes, dando suporte para um armazenamento de índice com maior disponibilidade geral para quando os requisitos de latência de consulta forem 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 é fornecido.
Contratos de nível de serviço
As versões prévias do recurso e a Camada gratuita não são cobertas pelos SLAs (Contratos de Nível de Serviço). Para todas as camadas faturáveis, os SLAs entram em vigor quando você provisiona redundância suficiente para o serviço. Você precisa ter duas ou mais réplicas para SLAs de consulta (leitura). 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 da capacidade
Permitir que as métricas sejam criadas com base em consultas e coletar dados sobre os padrões de uso (consultas durante o horário comercial, indexação fora do horário de pico). Use esses dados para informar as decisões de provisionamento do serviço. Embora não seja prático fazer isso a cada hora ou diariamente, você pode ajustar dinamicamente partições e recursos para acomodar alterações planejadas em volumes de consulta. Você também pode acomodar alterações não planejadas, mas contínuas, se os níveis são mantidos por tempo suficiente para garantir a tomada de ações.
Lembre-se de que a única desvantagem do subprovisionamento é que talvez você precise desativar um serviço se os requisitos reais forem maiores que o previsto. Para evitar a interrupção do serviço, crie um serviço em uma camada superior e execute-o lado a lado até que todos os aplicativos e solicitações sejam direcionados para o novo ponto de extremidade.
Quando adicionar capacidade
Inicialmente, um serviço é alocado a um nível mínimo de recursos compostos por uma partição e uma réplica. A camada escolhida determina o tamanho e a velocidade da partição, e cada camada é otimizada levando em consideração um conjunto de características que se ajustam a vários cenários. Se você escolher uma camada superior, poderá precisar de menos partições do que se você usar a S1. Uma das perguntas que você precisará responder por meio de testes autodirecionados é se uma partição maior e mais cara produz um desempenho melhor do que duas partições mais baratas em um serviço provisionado em uma camada inferior.
Um único serviço deve ter recursos suficientes para manipular 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 sejam naturalmente menos frequentes, mas o serviço não priorizará uma tarefa em vez da outra. Além disso, certa quantidade de redundância otimizará o desempenho da consulta quando os serviços ou nós forem atualizados internamente.
Algumas das diretrizes para determinar se a capacidade deve ser adicionada são:
- Atender aos critérios de alta disponibilidade do SLA
- A frequência de erros HTTP 503 está aumentando
- Grandes volumes de consulta são esperados
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 direcionadas para as cargas de trabalho de consulta. Cada réplica é uma cópia do seu índice e permite que o serviço realize o balanceamento de carga das solicitações nas várias cópias. Todo o balanceamento de carga e a replicação de um índice são gerenciados pela IA do Azure Search e você pode alterar o número de réplicas alocadas para o serviço a qualquer momento. É possível alocar até 12 réplicas em um serviço de pesquisa Standard e três réplicas em um serviço de pesquisa Básico. A alocação de réplicas pode ser feita no portal do Azure ou em uma das opções programáticas.
Aplicativos de pesquisa que exigem atualização de dados quase em tempo real precisarão proporcionalmente de mais partições de réplicas. A adição de partições distribui as operações de leitura/gravação em uma quantidade maior de recursos de computação. Também oferece mais espaço em disco para armazenar documentos e índices adicionais.
Por fim, índices maiores levam mais tempo para consultar. Assim, você poderá perceber que cada aumento incremental em partições requer um aumento proporcional, mas menor, em réplicas. A complexidade de suas consultas e seu volume influenciarão a rapidez com que a execução da consulta é retornada.
Observação
Adicionar mais réplicas ou partições aumenta o custo da execução do serviço e pode causar pequenas variações na ordenação dos resultados. Verifique a calculadora de preços para entender as implicações de cobrança da adição de mais nós. O gráfico abaixo pode ajudar você a fazer referência cruzada do número de unidades de pesquisa necessárias para uma configuração específica. Para obter mais informações sobre como as réplicas adicionais afetam o processamento da consulta, confira Ordenação de 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 Standard Básico provisionado com uma réplica e partição. A fórmula na parte inferior indica quantas unidades de pesquisa estão sendo usadas (1). Se o preço unitário era US$ 100 (preço fictício), o custo mensal da execução desse serviço seria de US$ 100 em média.
Use o controle deslizante para aumentar ou diminuir o número de partições. Selecione Salvar.
Este exemplo adiciona uma segunda réplica e partição. Observe a contagem de unidades de pesquisa. No momento, a contagem é quatro porque a fórmula de cobrança é o resultado das réplicas multiplicadas pelas partições (2 x 2). Dobrar a capacidade mais que dobra o custo da execução do serviço. Se o custo da unidade de pesquisa fosse US$ 100, a nova fatura mensal seria US$ 400.
Para obter os custos por unidade atuais de cada camada, visite a Página de preços.
Depois de salvar, você pode verificar as notificações para confirmar se a ação foi bem-sucedida.
As alterações na capacidade podem levar de 15 minutos até várias horas para serem concluídas. Não é possível cancelar após o início do processo e não há monitoramento em tempo real para os ajustes de réplica e partição. No entanto, a mensagem a seguir permanecerá visível enquanto as alterações estiverem em andamento.
Observação
Após o provisionamento de um serviço, ele não pode ser atualizado para uma camada superior. Você precisará criar um serviço de pesquisa no novo tipo e recarregar os índices. Confira Criar um serviço de IA do Azure Search no portal para obter ajuda com o provisionamento de serviço.
Como as solicitações de escala são administradas
Após o recebimento de uma solicitação 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.
A escala de um serviço pode levar apenas 15 minutos ou 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 iniciará o provisionamento quando ele puder fazer isso com segurança, o que pode ser enquanto o backup estiver terminando.
Erros durante a escala
A mensagem de erro "Operações de atualização de serviço não são permitidas no momento porque estamos processando uma solicitação anterior" é causada pela repetição de uma solicitação para reduzir ou escalar verticalmente quando o serviço já está processando uma solicitação anterior.
Resolva esse erro verificando o status do serviço para verificar o status de provisionamento:
- Use a API REST de gerenciamento, o Azure PowerShell ou a CLI do Azure para obter o status do serviço.
- Chame Obter serviço (REST) ou equivalente para o PowerShell ou a CLI.
- Verifique a resposta de "provisioningState": "provisioning"
Se o status for "Provisionamento", aguarde a conclusão da solicitação. O status deve ser "Succeeded" ou "Failed" para que seja possível tentar realizar outra solicitação. 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 parece estar paralisado em um estado de provisionamento, verifique se há índices órfãos inutilizáveis, sem volumes de consulta e sem atualizações de índice. Um índice inutilizável pode bloquear alterações na capacidade do serviço. Em especial, procure índices que estão criptografados por CMK, cujas chaves estão inválidas. Você deve excluir o índice ou restaurar as chaves para colocar o índice online novamente e desbloquear a operação de escala dele.
Combinações de partição e réplica
Nos serviços de pesquisa criados antes de 3 de abril de 2024: o Básico pode ter exatamente uma partição e até três réplicas, para um limite máximo de três unidades de armazenamento. 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 com suporte: o Básico pode ter até três partições e três réplicas. O limite máximo de unidade de armazenamento é nove para dar suporte a um complemento completo de partições e réplicas.
Para serviços de pesquisa em qualquer camada faturável, independentemente da data de criação, você precisará de um mínimo de duas réplicas para alta disponibilidade em consultas.
Todos os serviços de pesquisa Standard e Otimizado para Armazenamento podem ter as combinações de réplicas e partições a seguir, sujeitas ao limite de 36 SUs permitido para essas camadas.
| 1 partição | 2 partições | 3 partições | 4 partições | 6 partições | 12 partições | |
|---|---|---|---|---|---|---|
| 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/D |
| 5 réplicas | 5 SU | 10 SU | 15 SU | 20 SU | 30 SU | N/D |
| 6 réplicas | 6 SU | 12 SU | 18 SU | 24 SU | 36 SU | N/D |
| 12 réplicas | 12 SU | 24 SU | 36 SU | N/D | N/D | N/D |
SUs, preço e capacidade são explicados detalhadamente no site do Azure. Para obter mais informações, consulte Detalhes de Preço.
Observação
O número de réplicas e partições divide de maneira uniforme em 12 (especificamente, 1, 2, 3, 4, 6 e 12). A IA do Azure Search divide previamente cada índice em 12 fragmentos, para que ele possa ser distribuído em partes iguais entre 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. A maneira como a IA do Azure 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 ele seja sempre 12 no futuro.