Dicas para melhorar o desempenho do Azure AI Search

Este artigo é uma coleção de dicas e práticas recomendadas para aumentar o desempenho de consulta e indexação de palavras-chave. Saber quais fatores são mais propensos a afetar o desempenho da pesquisa pode ajudá-lo a evitar ineficiências e aproveitar ao máximo seu serviço de pesquisa. Os principais fatores incluem:

• Composição de índice (esquema e tamanho)
• Design de consulta
• Capacidade do serviço (camada e o número de réplicas e partições)

Tamanho e esquema do índice

As consultas são executadas mais rapidamente com índices menores. Isso é, em parte, em função de ter menos campos a ser verificados, mas também devido a como o sistema armazena em cache o conteúdo para consultas futuras. Após a primeira consulta, parte do conteúdo permanece na memória, onde é pesquisada com mais eficiência. Como o tamanho do índice tende a crescer ao longo do tempo, uma prática recomendada é revisitar periodicamente a composição do índice, do esquema e dos documentos, para procurar oportunidades de redução de conteúdo. No entanto, se o índice for do tamanho certo, a única outra calibragem que você pode fazer é aumentar a capacidade atualizando seu serviço, adicionando réplicas ou alternando para um tipo de preço mais alto. A seção "Dica: Atualizar para um nível Standard S2" fala sobre a decisão de escalar verticalmente versus escalar horizontalmente.

A complexidade do esquema também pode afetar de modo negativo a indexação e o desempenho da consulta. A atribuição excessiva de campos acarreta limitações e requisitos de processamento. Os Tipos complexos levam mais tempo para indexar e consultar. As próximas seções exploram cada condição.

Dica: Ser seletivo na atribuição de campo

Um erro comum que os administradores e os desenvolvedores cometem ao criar um índice de pesquisa é selecionar todas as propriedades disponíveis para os campos, em vez de selecionar somente as propriedades necessárias. Por exemplo, se um campo não precisar ser pesquisável com texto completo, pule esse campo ao definir o atributo pesquisável.

O suporte para filtros, facetas e classificações pode quadruplicar os requisitos de armazenamento. Se você adicionar sugestores, os requisitos de armazenamento aumentarão ainda mais. Para obter uma ilustração sobre o impacto dos atributos no armazenamento, consulte Atributos e tamanho do índice.

Resumindo, as ramificações do excesso de atribuição incluem:

• Degradação do desempenho de indexação devido ao trabalho extra necessário para processar o conteúdo no campo e, em seguida, armazená-lo no índice invertido de pesquisa (definir o atributo "pesquisável" somente em campos que contenham conteúdo pesquisável).

• Cria uma superfície maior que cada consulta deve cobrir. Todos os campos marcados como pesquisáveis são verificados em uma pesquisa de texto completo.

• Aumentam os custos operacionais devido ao armazenamento extra. Filtrar e classificar requer espaço adicional para armazenar cadeias de caracteres originais (não analisadas). Evite configurar campos como filtráveis ou classificáveis quando não for necessário.

• Em muitos casos, o excesso de atribuição limita as capabilidades do campo. Por exemplo, se um campo for facetável, filtrável e pesquisável, somente poderá armazenar 16 KB de texto, enquanto um campo pesquisável pode conter até 16 MB de texto.

Dica: Considerar alternativas para tipos complexos

Tipos de dados complexos são úteis quando os dados têm uma estrutura aninhada complicada, como os elementos pai-filho encontrados em documentos JSON. A desvantagem dos tipos complexos são os requisitos de armazenamento extra e os recursos adicionais necessários para indexar o conteúdo, em comparação com tipos de dados não complexos.

Em alguns casos, é possível evitar essas compensações mapeando uma estrutura de dados complexa para um tipo de campo mais simples, como uma Coleção. Como alternativa, é possível optar por nivelar uma hierarquia de campo em campos de nível raiz individuais.

Design de consulta

A composição e a complexidade da consulta são um dos fatores mais importantes para o desempenho, e otimizar a consulta pode melhorar drasticamente o desempenho. Ao criar consultas, pense nos seguintes pontos:

• Número de campos pesquisáveis. Cada campo pesquisável adicional resulta em mais trabalho para o serviço de pesquisa. É possível limitar os campos que serão pesquisados no momento da consulta usando o parâmetro "searchFields". É melhor especificar apenas os campos nos quais há preocupação em melhorar o desempenho.

• Quantidade de dados retornados. Recuperar uma grande quantidade de conteúdo pode tornar as consultas mais lentas. Ao estruturar uma consulta, retorne apenas os campos necessários para renderizar a página resultados e, em seguida, recupere os campos restantes usando a API de pesquisa quando um usuário selecionar uma correspondência.

• Uso de pesquisas de termo parcial.Pesquisas de termo parcial, como pesquisa de prefixo, pesquisa difusa e pesquisa de expressão regular, são mais caras em termos de computação de palavras-chave comuns, pois exigem verificações de índice completas para produzir resultados.

• Número de facetas. Adicionar facetas a consultas requer agregações para cada consulta. Solicitar uma "contagem" maior para uma faceta também requer trabalho extra pelo serviço. Em geral, adicione apenas as facetas que você planeja renderizar no aplicativo e evite solicitar uma contagem alta para facetas, a menos que necessário.

• Valores de ignoração altos. Definir o parâmetro $skip como um valor alto (por exemplo, em milhares) aumenta a latência de pesquisa porque o mecanismo está recuperando e classificando um volume maior de documentos para cada solicitação. Por motivos de desempenho, é melhor evitar valores $skip altos e usar outras técnicas, como filtragem, para recuperar um grande número de documentos.

• Limitar campos de alta cardinalidade. Um campo de alta cardinalidade refere-se a um campo facetável ou filtrável que tem um número considerável de valores exclusivos e, como resultado, consome recursos significativos no cálculo dos resultados. Por exemplo, a configuração de um campo de ID ou Descrição do Produto como facetável e filtrável seria considerado de alta cardinalidade, pois a maioria dos valores de documento para documento é única.

Dica: Usar as funções de pesquisa em vez de sobrecarregar os critérios de filtro

Como uma consulta usa, cada vez mais critérios de filtro complexos, o desempenho da consulta de pesquisa ficará prejudicado. Considere o exemplo a seguir que demonstra o uso de filtros para cortar resultados com base em uma identidade de usuário:

$filter= userid eq 123 or userid eq 234 or userid eq 345 or userid eq 456 or userid eq 567

Nesse caso, as expressões de filtro são usadas para verificar se um único campo em cada documento é igual a um dos muitos valores possíveis de uma identidade de usuário. É mais provável encontrar esse padrão em aplicativos que implementam a filtragem de segurança (verificar um campo que contém uma ou mais IDs de entidade de segurança em relação a uma lista de IDs de entidades de segurança que representam o usuário que está emitindo a consulta).

Uma maneira mais eficiente de executar filtros que contêm um grande número de valores é usar a search.in função, conforme mostrado neste exemplo:

search.in(userid, '123,234,345,456,567', ',')

Dica: Adicionar partições para consultas individuais lentas

Quando o desempenho da consulta está diminuindo de modo geral, adicionar mais réplicas geralmente resolve o problema. Mas, e se o problema for uma única consulta que leva muito tempo para ser concluída? Nesse cenário, a adição de réplicas não ajudará, mas talvez partições adicionais ajudem. Uma partição divide os dados em recursos de computação extra. Duas partições dividem os dados pela metade, uma terceira partição divide-os em terços e assim por diante.

Um efeito colateral positivo da adição de partições é que as consultas mais lentas às vezes são executadas mais rapidamente devido à computação paralela. Observamos a paralelização em consultas de baixa seletividade, como consultas que correspondem a muitos documentos ou facetas que fornecem contagens de um grande número de documentos. Como uma computação significativa é necessária para pontuar a relevância dos documentos ou para contar os números de documentos, adicionar partições extras ajuda as consultas a serem concluídas com mais rapidez.

Para adicionar partições, use o portal do Azure, o PowerShell, a CLI do Azure ou um SDK de gerenciamento.

Capacidade do serviço

Um serviço é sobrecarregado quando as consultas levam muito tempo ou quando o serviço começa a cancelar as solicitações. Se isso acontecer, é possível resolver o problema atualizando o serviço ou adicionando capacidade.

A camada do serviço de pesquisa e o número de réplicas/partições também têm um grande impacto sobre o desempenho. Cada camada progressivamente mais alta fornece CPUs mais rápidas e mais memória, que têm um impacto positivo no desempenho.

Dica: crie um serviço de pesquisa de alta capacidade

Os serviços Básico e Standard criados em regiões com suporte após 3 de abril de 2024 têm mais armazenamento por partição do que os serviços mais antigos. Se você tiver um serviço mais antigo, verifique se pode atualizar seu serviço para se beneficiar de mais capacidade na mesma taxa de cobrança. Se uma atualização não estiver disponível, examine os limites de serviço de camada para ver se a mesma camada em um serviço mais recente fornece o armazenamento necessário.

Dica: alternar para uma camada S2 Standard

A camada de pesquisa Standard S1 geralmente é onde os clientes iniciam. Um padrão comum para serviços S1 é que os índices crescem ao longo do tempo, o que exige mais partições. Mais partições levam a tempos de resposta mais lentos, portanto, mais réplicas são adicionadas para lidar com a carga de consulta. Como você pode imaginar, o custo da execução de um serviço S1 agora progrediu para níveis além da configuração inicial.

Neste momento, uma pergunta importante a ser feita é se seria benéfico mudar para uma camada de preços mais alta, em vez de aumentar progressivamente o número de partições ou réplicas do serviço atual.

Considere a seguinte topologia como um exemplo de um serviço que obteve níveis crescentes de capacidade:

• Camada Standard S1
• Tamanho do índice: 190 GB
• Contagem de partições: 8 (em S1, o tamanho da partição é 25 GB por partição)
• Contagem de Réplicas: 2
• Total de Unidades de pesquisa: 16 (8 partições x 2 réplicas)
• Preço hipotético de varejo: ~US$ 4.000 /mês (suponha 250 USD x 16 unidades de pesquisa)

Suponha que o administrador de serviços ainda observe taxas de latência mais altas e esteja considerando adicionar outra réplica. Isso alteraria a contagem de réplicas de 2 para 3 e, como resultado, alteraria a contagem de unidades de pesquisa para 24 e um preço resultante de $6.000 USD/mês.

No entanto, se o administrador optasse por mudar para uma camada Standard S2, a topologia teria esta aparência:

• Camada Standard S2
• Tamanho do índice: 190 GB
• Contagem de partições: 2 (na S2, o tamanho da partição é 100 GB por partição)
• Contagem de Réplicas: 2
• Total de Unidades de Pesquisa: 4 (2 partições x 2 réplicas)
• Preço hipotético de varejo: ~US$ 4.000 USD/mês (1.000 USD x 4 unidades de pesquisa)

Como este cenário hipotético ilustra, é possível ter configurações em camadas inferiores que resultam em custos semelhantes, como se tivesse optado por uma camada mais alta desde o início. No entanto, as camadas mais altas são fornecidas com o armazenamento Premium, o que torna a indexação mais rápida. As camadas mais altas também têm muito mais poder de computação, bem como memória extra. Para os mesmos custos, é possível ter uma infraestrutura mais potente de suporte para o mesmo índice.

Um benefício importante da memória adicionada é que pode ser armazenado em cache uma parte maior do índice, resultando em latência de pesquisa mais baixa e um número maior de consultas por segundo. Com essa potência extra, talvez o administrador não precise nem mesmo aumentar a contagem de réplicas e pode pagar menos do que permanecendo no serviço S1.

Dica: considere alternativas para consultas de expressão regular

As consultas de expressão regular ou regex podem ser particularmente caras. Embora possam ser muito úteis para pesquisas avançadas, a execução pode exigir muito poder de processamento, especialmente se a expressão regular for complicada ou se você estiver pesquisando uma grande quantidade de dados. Todos esses fatores contribuem para a alta latência de pesquisa. Como mitigação, tente simplificar a expressão regular ou dividir a consulta complexa em consultas menores e mais gerenciáveis.

Próximas etapas

Examine estes outros artigos relacionados ao desempenho do serviço:

• Análise de desempenho
• Indexar grandes conjuntos de dados no Azure AI Search
• Escolher uma camada de serviço
• Planejar ou adicionar capacidade
• Estudo de caso: usar o Cognitive Search para suporte a cenários complexos de IA