Estimar e gerir a capacidade de um serviço de pesquisa

Antes de criar um serviço de pesquisa e bloquear um nível de preços específico, desloque alguns minutos para entender como funciona a capacidade e como pode ajustar réplicas e divisórias para acomodar a flutuação da carga de trabalho.

Em Azure Cognitive Search, a capacidade baseia-se em réplicas e divisórias que podem ser dimensionada para a sua carga de trabalho. Réplicas são cópias do motor de busca. As divisórias são unidades de armazenamento. Cada novo serviço de pesquisa começa com um cada, mas pode ajustar cada unidade de forma independente para acomodar cargas de trabalho flutuantes. Adicionar qualquer uma das unidades é faturada.

As características físicas das réplicas e divisórias, tais como a velocidade de processamento e a IO do disco, variam de acordo com o nível de serviço. Se forte no Standard, réplicas e divisórias serão mais rápidas e maiores do que as do Basic.

Mudar a capacidade não é instantâneo. Pode levar até uma hora para encomendar ou desativar divisórias, especialmente em serviços com grandes quantidades de dados.

Ao escalar um serviço de pesquisa, pode escolher entre as seguintes ferramentas e abordagens:

Conceitos: unidades de pesquisa, réplicas, divisórias, fragmentos

A capacidade é expressa em unidades de busca que podem ser alocadas em combinações de divisórias e réplicas, utilizando um mecanismo de fragmento 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 para um serviço de Azure Cognitive Search. É necessário um mínimo de uma unidade para executar o serviço.
Réplica Casos do serviço de pesquisa, usado principalmente para carregar operações de consulta de equilíbrio. Cada réplica acolhe uma cópia de um índice. Se atribuir três réplicas, terá três cópias de um índice disponível para pedidos de consulta.
Partição Armazenamento físico e E/S para operações de leitura/escrita (por exemplo, ao reconstruir ou refrescar um índice). Cada divisória tem uma fatia do índice total. Se atribuir três divisórias, o seu índice é dividido em terços.
Fragmento Um pedaço de um índice. Azure Cognitive Search divide cada índice em fragmentos para tornar o processo de adição de divisórias mais rápido (movendo fragmentos para novas unidades de pesquisa).

O diagrama seguinte mostra a relação entre réplicas, divisórias, fragmentos e unidades de busca. Mostra um exemplo de como um único índice é distribuído por quatro unidades de pesquisa num serviço com duas réplicas e duas divisórias. Cada uma das quatro unidades de pesquisa armazena apenas metade dos fragmentos do índice. As unidades de busca na coluna esquerda armazenam a primeira metade dos fragmentos, compreendendo a primeira divisória, enquanto as da coluna direita armazenam a segunda metade dos fragmentos, compreendendo a segunda divisória. Como há duas réplicas, há duas cópias de cada fragmento de índice. As unidades de pesquisa na primeira fila armazenam uma cópia, compreendendo a primeira réplica, enquanto as da linha inferior armazenam outra cópia, compreendendo a segunda réplica.

Os índices de pesquisa são fragmentos através de divisórias.

O diagrama acima é apenas um exemplo. Muitas combinações de divisórias e réplicas são possíveis, até um máximo de 36 unidades de pesquisa totais.

Na Pesquisa Cognitiva, a gestão de fragmentos é um detalhe de implementação e não configurável, mas saber que um índice é fragmento ajuda a entender as anomalias ocasionais no ranking e comportamentos autocompletos:

  • Anomalias no ranking: As pontuações de pesquisa são calculadas primeiro no nível de fragmento e, em seguida, agregadas num único conjunto de resultados. Dependendo das características do conteúdo de fragmentos, os jogos de um fragmento podem ser classificados acima dos fósforos em outro. Se notar rankings contraintuitivos nos resultados da pesquisa, é mais provável que seja devido aos efeitos do fragmento, especialmente se os índices forem pequenos. Pode evitar estas anomalias no ranking, optando por calcular pontuações globalmente em todo o índice, mas fazê-lo incorrerá numa penalidade de desempenho.

  • Anomalias autocompletas: Consultas autocompletas, onde os jogos são feitos nos primeiros caracteres de um termo parcialmente introduzido, aceitam um parâmetro difuso que perdoa pequenos desvios na ortografia. Para a correspondência autocompleta, a correspondência difusa é limitada aos termos dentro do fragmento atual. Por exemplo, se um fragmento contiver "Microsoft" e for introduzido um termo parcial de "micor", o motor de busca corresponderá a "Microsoft" nesse fragmento, mas não em outros fragmentos que mantenham as partes restantes do índice.

Aproximação da estimativa

A capacidade e os custos de funcionamento do serviço andam de mãos dadas. Os níveis impõem limites a dois níveis: conteúdo (uma contagem de índices num serviço, por exemplo) e armazenamento. É importante considerar ambos porque qualquer que seja o limite que se atinge primeiro é o limite efetivo.

Os condes de índices e outros objetos são tipicamente ditados pelos requisitos de negócio e engenharia. Por exemplo, pode ter várias versões do mesmo índice para desenvolvimento ativo, testes e produção.

As necessidades de armazenamento são determinadas pelo tamanho dos índices que espera construir. Não há heurística sólida ou generalidades que ajudem com estimativas. A única maneira de determinar o tamanho de um índice é construir um. O seu tamanho basear-se-á em dados importados, análise de texto e configuração de índices, tais como se permite sugestores, filtragem e triagem.

Para a pesquisa completa de texto, a estrutura de dados primários é uma estrutura de índice invertida , 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 se alimenta nele. Uma grande fonte de dados com alta redundância poderia resultar num í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, tais como a ativação de filtros e a triagem, terão impacto nos requisitos de armazenamento. O uso de sugestivos também tem implicações de armazenamento. Para obter mais informações, consulte Atributos e tamanho do índice.

Nota

Embora estimar necessidades futuras de índices e armazenamento possa parecer adivinhação, vale a pena fazê-lo. Se a capacidade de um nível se revelar demasiado baixa, terá de providenciar um novo serviço a um nível mais elevado e, em seguida, recarregar os seus índices. Não há um upgrade no lugar de um serviço de um nível para outro.

Estimativa com o nível Livre

Uma abordagem para estimar a capacidade é começar com o nível Livre. 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 um desafio estimar um tamanho de índice projetado com estes constrangimentos, mas estes são os passos:

  • Crie um serviço gratuito.

  • Prepare um conjunto de dados pequeno e representativo.

  • Crie um índice e carregue os seus dados. Se o conjunto de dados puder ser hospedado numa fonte de dados Azure suportada por indexadores, pode utilizar o assistente de dados De importação no portal para criar e carregar o índice. Caso contrário, pode usar REST e Carteiro para criar o índice e empurrar os dados. O modelo push requer que os dados sejam sob a forma de documentos JSON, onde os campos no documento correspondem aos campos do índice.

  • Recolher informações sobre o índice, como tamanho. Funcionalidades e atributos têm impacto no armazenamento. Por exemplo, adicionar sugestivos (consultas de pesquisa à sua medida) aumentará os requisitos de armazenamento.

    Utilizando o mesmo conjunto de dados, pode tentar criar várias versões de um índice, com diferentes atributos em cada campo, para ver como os requisitos de armazenamento variam. Para obter mais informações, consulte "Implicações de armazenamento" na Criação de um índice básico.

Com uma estimativa aproximada na mão, você pode duplicar esse montante para orçamento para dois índices (desenvolvimento e produção) e, em seguida, escolher o seu nível em conformidade.

Estimativa com um nível faturada

Os recursos dedicados podem acomodar tempos de amostragem e processamento maiores para estimativas mais realistas de volumes de quantidade, tamanho e consulta de índice durante o desenvolvimento. Alguns clientes saltam para dentro com um nível de faturação e depois reavaliam à medida que o projeto de desenvolvimento amadurece.

  1. Reveja os limites de serviço em cada nível para determinar se os níveis mais baixos podem suportar o número de índices de que necessita. Nos escalões Básico, S1 e S2, os limites de índice são de 15, 50 e 200, respectivamente. O nível otimizado de armazenamento tem um limite de 10 índices porque é projetado para suportar um número baixo de índices muito grandes.

  2. Criar um serviço num nível de faturação:

    • Comece baixo, no Basic ou S1, se não tiver certeza sobre a carga projetada.
    • Comece alto, no S2 ou mesmo no S3, se os testes incluirem indexação em larga escala e cargas de consulta.
    • Comece com o Storage Otimizado, em L1 ou L2, se estiver a indexar uma grande quantidade de dados e a carga de consulta é relativamente baixa, como acontece com uma aplicação de negócio interna.
  3. Construa um índice inicial para determinar como os dados de origem se traduzem num índice. Esta é a única maneira de estimar o tamanho do índice.

  4. Monitorar armazenamento, limites de serviço, volume de consulta e latência no portal. O portal mostra-lhe consultas por segundo, consultas estranguladas e latência de pesquisa. Todos estes valores podem ajudá-lo a decidir se selecionou o nível certo.

  5. Adicione réplicas se precisar de alta disponibilidade ou se experimentar um desempenho de consulta lenta.

    Não existem 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 num melhor desempenho, o resultado não é estritamente linear: adicionar três réplicas não garante o triplo rendimento. Para obter orientações para estimar o QPS para a sua solução, consulte Scale paraobter consultas de desempenho e monitor.

Nota

Os requisitos de armazenamento podem ser insuflados se 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 são pesmáveis e devem ser armazenados separadamente (talvez numa mesa Azure ou armazenamento de bolhas). Um campo deve então ser adicionado no índice para manter uma referência URL aos dados externos. O tamanho máximo de um documento de pesquisa individual é de 16 MB (ou menos se estiver a carregar vários documentos num único pedido). Para mais informações, consulte os limites de serviço em Azure Cognitive Search.

Considerações de volume de consulta

Consultas por segundo (QPS) é uma métrica importante durante a afinação do desempenho, mas geralmente é apenas uma consideração de nível se você espera um alto volume de consulta no início.

Os níveis Standard podem fornecer um equilíbrio de réplicas e divisórias. Pode aumentar a reviravolta da consulta adicionando réplicas para equilibrar a carga ou adicionar divisórias para processamento paralelo. Em seguida, pode sintonizar para desempenho após o serviço ser prestado.

Se espera volumes de consultas de alta sustentação desde o início, deve considerar níveis standard mais elevados, apoiados por hardware mais potente. Em seguida, pode tirar divisórias e réplicas offline, ou até mesmo mudar para um serviço de nível inferior, se esses volumes de consulta não ocorrerem. Para obter mais informações sobre como calcular a produção de consulta, consulte Azure Cognitive Search desempenho e otimização.

Os níveis otimizados de armazenamento são úteis para grandes cargas de trabalho de dados, suportando um armazenamento de índice mais disponível para quando os requisitos de latência de consulta são menos importantes. Deve ainda utilizar réplicas adicionais para equilibrar cargas e divisórias adicionais para processamento paralelo. Em seguida, pode sintonizar para desempenho após o serviço ser prestado.

Acordos de nível de serviço

As funcionalidades de nível gratuito e de pré-visualização não estão abrangidas por acordos de nível de serviço (SLAs). Para todos os níveis de faturação, as SLAs fazem efeito quando forneces despedimentos suficientes para o teu serviço. Precisa de ter duas ou mais réplicas para consulta (ler) SLAs. Precisa de três ou mais réplicas para consulta e indexação (ler-escrever) SLAs. O número de divisórias não afeta as AEA.

Dicas para planeamento de capacidades

  • Permitir que as métricas construam em torno de consultas e recolham dados em torno dos padrões de utilização (consultas durante o horário comercial, indexação durante as horas de ponta). Utilize estes dados para informar as decisões de prestação de serviços. Embora não seja prático a uma cadência de hora ou de trabalho, pode ajustar dinamicamente as divisórias e recursos para acomodar as mudanças planeadas nos volumes de consulta. Também pode acomodar alterações não planeadas mas sustentadas se os níveis aguentarem o tempo suficiente para justificar a tomada de medidas.

  • Lembre-se que a única desvantagem do fornecimento é que você pode ter que demolir um serviço se os requisitos reais são maiores do que as suas previsões. Para evitar perturbações no serviço, criaria um novo serviço num nível mais alto e executá-loá lado a lado até que todas as aplicações e pedidos direcionem o novo ponto final.

Quando adicionar capacidade

Inicialmente, é atribuído um serviço a um nível mínimo de recursos constituído por uma divisória e uma réplica. O nível que escolhe determina o tamanho e a velocidade da partição, e cada nível é otimizado em torno de um conjunto de características que se encaixam em vários cenários. Se escolher um nível de gama superior, poderá precisar de menos divisórias do que se for com S1. Uma das perguntas que terá de responder através de testes auto-dirigidos é se uma partição maior e mais cara produz melhor desempenho do que duas divisórias mais baratas num serviço prestado num nível inferior.

Um único serviço deve ter recursos suficientes para lidar com todas as cargas de trabalho (indexação e consultas). Nenhuma carga de trabalho corre em segundo plano. Pode agendar a indexação para os momentos em que os pedidos de consulta são naturalmente menos frequentes, mas o serviço não priorizará uma tarefa em relação a 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 orientações para determinar se adicionar capacidade incluem:

  • Cumprimento dos elevados critérios de disponibilidade para o acordo de nível de serviço
  • A frequência dos erros HTTP 503 está a aumentar
  • Esperam-se grandes volumes de consultas

Regra geral, as aplicações de pesquisa tendem a necessitar de mais réplicas do que divisórias, especialmente quando as operações de serviço são tendenciosas para consultas de carga de trabalho. Cada réplica é uma cópia do seu índice, permitindo ao serviço carregar pedidos de saldo contra várias cópias. Todo o equilíbrio de carga e replicação de um índice é gerido por Azure Cognitive Search e pode alterar o número de réplicas atribuídas ao seu serviço a qualquer momento. Pode alocar até 12 réplicas num serviço de pesquisa Standard e 3 réplicas num serviço de pesquisa Básico. A atribuição de réplicas pode ser feita a partir do portal do Azure ou de uma das opções programáticas.

As aplicações de pesquisa que requerem uma atualização de dados em tempo real precisarão proporcionalmente mais de divisórias do que réplicas. A adição de divisórias espalha operações de leitura/escrita através de um maior número de recursos computacional. Também lhe dá mais espaço para armazenar índices e documentos adicionais.

Finalmente, índices maiores demoram mais tempo a consultar. Como tal, pode descobrir que cada aumento incremental de divisórias requer um aumento menor, mas proporcional, de réplicas. A complexidade das suas consultas e volume de consultas irá ter em conta a rapidez com que a execução de consultas é virada.

Nota

Adicionar mais réplicas ou divisórias aumenta o custo de execução do serviço, e pode introduzir ligeiras variações na forma como os resultados são encomendados. Certifique-se de verificar a calculadora de preços para entender as implicações de faturação de adicionar mais nós. O gráfico abaixo pode ajudá-lo a cruzar o 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 impactam o processamento da consulta, consulte os resultados de Encomenda.

Adicione ou reduza réplicas e divisórias

  1. Inscreva-se no portal do Azure e selecione o serviço de pesquisa.

  2. Em Definições, abra a página Escala para modificar réplicas e divisórias.

    A imagem a seguir mostra uma Norma Básica a provisionada com uma réplica e partição. A fórmula na parte inferior indica quantas unidades de busca estão a ser utilizadas (1). Se o preço unitário fosse $100 (não um preço real), o custo mensal de execução deste serviço seria de $100, em média.

    Página de escala mostrando valores atuais

  3. Utilize o deslizador para aumentar ou diminuir o número de divisórias. Selecione Guardar.

    Este exemplo adiciona uma segunda réplica e partição. Note a contagem da unidade de pesquisa; são agora quatro porque a fórmula de faturação é réplica multiplicada por divisórias (2 x 2). Duplicar a capacidade mais do que duplica o custo de funcionamento do serviço. Se o custo da unidade de pesquisa fosse $100, a nova conta mensal seria agora $400.

    Para os custos atuais por unidade de cada nível, visite a página de Preços.

    Adicionar réplicas e divisórias

  4. Depois de poupar, pode verificar notificações para confirmar que a ação foi bem sucedida.

    Guardar alterações

    As mudanças de capacidade podem demorar entre 15 minutos e várias horas para ser concluída. Não é possível cancelar uma vez iniciado o processo e não existe monitorização em tempo real para ajustes de replicação e partição. No entanto, a seguinte mensagem permanece visível enquanto as alterações estão em curso.

    Mensagem de estado no portal

Nota

Depois de um serviço ser prestado, não pode ser atualizado para um nível mais elevado. Tem de criar um serviço de pesquisa no novo nível e recarregar os seus índices. Consulte Criar um serviço de Azure Cognitive Search no portal para obter ajuda na prestação de serviços.

Como os pedidos de escala são tratados

Após a receção de um pedido de escala, o serviço de pesquisa:

  1. Verifica se o pedido é válido.
  2. Começa a fazer o backup de dados e informações do sistema.
  3. Verifique se o serviço já se encontra em estado de provisionamento (atualmente adicionando ou eliminando réplicas ou divisórias).
  4. Começa a provisão.

A escala de um serviço pode demorar apenas 15 minutos ou bem mais de uma hora, dependendo do tamanho do serviço e do âmbito do pedido. A cópia de segurança pode demorar vários minutos, dependendo da quantidade de dados e do número de divisórias e réplicas.

Os passos acima não são inteiramente consecutivos. Por exemplo, o sistema começa a fornecer quando pode fazê-lo com segurança, o que pode ser enquanto a cópia de segurança está a acabar.

Erros durante o escalonamento

A mensagem de erro "As operações de atualização de serviço não são permitidas neste momento porque estamos a processar um pedido anterior" é causada pela repetição de um pedido de escala para baixo ou para cima quando o serviço já está a processar um pedido anterior.

Resolver este erro verificando o estado do serviço para verificar o estado de provisionamento:

  1. Utilize a API de Gestão REST, Azure PowerShell ou Azure CLI para obter o estado de serviço.
  2. Serviço de Chamada Get
  3. Consulte a resposta para "ProvisioningState": "provisioning"

Se o estado for "Provisioning", então aguarde que o pedido esteja concluído. O estado deve ser "Bem sucedido" ou "Falhado" antes de se tentar outro pedido. Não há estatuto para reforços. A cópia de segurança é uma operação interna e é improvável que seja um fator em qualquer interrupção de um exercício de escala.

Combinações de partição e réplica

Um serviço básico pode ter exatamente uma divisória e até três réplicas, para um limite máximo de três SUs. O único recurso ajustável são réplicas. 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 divisórias, sob reserva do limite de 36 SU permitido para estes níveis.

1 partição 2 partições 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/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

As SUs, os preços e a capacidade são explicados em detalhe no site da Azure. Para mais informações, consulte detalhes de preços.

Nota

O número de réplicas e divisórias divide-se uniformemente em 12 (especificamente, 1, 2, 3, 4, 6, 12). Azure Cognitive Search pré-divide cada índice em 12 fragmentos para que possa ser espalhado em partes iguais em todas as divisórias. Por exemplo, se o seu serviço tiver três divisórias e criar um índice, cada divisória conterá quatro fragmentos do índice. Como Azure Cognitive Search fragmentos de um índice é um detalhe de implementação, sujeito a alterações em futuras versões. Embora o número seja 12 hoje, não deve esperar que esse número seja sempre 12 no futuro.

Passos seguintes