Dando sequência à série de estudos sobre o Azure Search, neste artigo eu apresento os principais recursos de pesquisa disponíveis neste serviço. Caso tenha perdido os artigos iniciais, segue aqui os links para o primeiro e o segundo.
Para todos os fins práticos, os recursos de busca são o principal meio de interação entre o desenvolvedor e o mecanismo de pesquisa que foi construído. Portanto, simplicidade de uso e a variedade de recursos são fatores essenciais, e o Azure Search é muito bom nestes dois quesitos, como se verá a seguir.
Apresento a seguir alguns casos de uso do serviço, mas antes preciso apresentar uma questão de segurança.
Uma palavra sobre segurança
Quando criamos um serviço do Azure Search, são geradas duas chaves de acesso para administração do serviço. Estas chaves dão acesso a tudo que existe dentro deste serviço e, através delas, posso inclusive apagar todos os índices existentes. Portanto, é evidente que estas chaves não devem ser compartilhadas.
Para resolver essa situação, posso criar no portal do Azure, chaves de acesso para consulta da base de conhecimentos. Esta é a chave que se compartilha com a aplicação que consome o serviço do Azure Search.
Para gerar esta(s) chave(s), basta clicar na guia “KEYS” e depois clicar no botão “MANAGE QUERY KEYS“, como mostra a imagem a seguir.
A partir de agora posso compartilhar a chave de consulta com a aplicação para que se tenha o nível de acesso limitado apenas ao que interessa: pesquisar a base de conhecimento.
Base de conhecimento destes exemplos
Como eu havia comentado já no primeiro artigo da série, preparei uma base de conhecimento contendo minhas próprias publicações para disponibilizar aos interessados um meio fácil de localizar artigos, podcasts e livros que publiquei.
Para melhor entendimento dos exemplos a seguir, tenha em mente a estrutura dos documentos desta base.
{
"id" : "31"
, "MIDIA" : "iMasters"
, "LINGUA" : "Português"
, "AUTOR" : "Wagner Crivelini"
, "TITULO" : "Dicas e truques para importação de arquivos em formato texto"
, "TEMA" : "Tem inúmeras coisas no mundo de TI que nos são vendidas como se fossem mais fáceis que roubar doce... "
, "DATA" : "03/12/2013"
, "LINK" : "https://imasters.com.br/banco-de-dados/dicas-e-truques-para-importacao-de-arquivos-em-formato-texto"
, "TAGS" : "arquivos texto"
}
Mais uma vez, usarei a ferramenta POSTMAN para consumir o serviço via API de REST.
Consultas básicas
No AZURE SEARCH, chamam-se consultas simples aquelas que utilizam recursos básicos de pesquisa, como busca de palavras, buscas com operadores (AND, OR ou NOT) e busca de sentenças exatas. O tipo de consulta a se executar é informado pelo parâmetro queryType, que por default tem o valor simple. Por esta razão, não precisamos nos preocupar com este parâmetro quando o objetivo é executar consultas simples.
Busca por palavras exatas
Neste primeiro exemplo, apresento como fazer uma busca em toda base de conhecimento buscando a palavra “cenário”.
- Busca 1: Pesquisa da palavra “cenário”
- Endpoint: https://wcrivelini-test1.search.windows.net/indexes/publications/docs?search=cenário&api-version=2016-09-01
- Verbo: GET
- Headers (usando chave de consulta): Content-type: application/JSON Api-Key: 4DDB0B46B1CE55768C1A8B062564DAC7 (observação: chave de consulta)
- Authorization: “No Auth”
- Body (raw): Vazio
- Body (resultado): (são encontrados quatro documentos que podem ser vistos neste link)
Note que o resultado de uma consulta simples sempre mostra os documentos que tem a palavra exata que foi pesquisada. A busca da palavra “cenário” retorna quatro documentos, mas a busca da palavra “cenários” tem que ser feita em separado e retorna apenas um documento.
Busca por sentença exata
No próximo exemplo, faço uma busca pela sentença “cenário que descrevo”. Veja que preciso apenas usar aspas duplas para especificar a busca exata. E desta vez, o serviço retorna apenas um documento.
- Busca 2: Pesquisa da palavra “cenário que descrevo”
- Endpoint: https://wcrivelini-test1.search.windows.net/indexes/publications/docs?search=”cenário que descrevo”&api-version=2016-09-01
- Verbo: GET
- Headers (usando chave de consulta): Content-type: application/JSON Api-Key: 4DDB0B46B1CE55768C1A8B062564DAC7
- Authorization: “No Auth”
- Body (raw): Vazio
Body (resultado):
{
"@odata.context": "https://wcrivelini-test1.search.windows.net/indexes('publications')/$metadata#docs",
"value": [
{
"@search.score": 0.25563234,
"id": "63",
"MIDIA": "iMasters",
"LINGUA": "Português",
"AUTOR": "Wagner Crivelini",
"TITULO": "Consultando Dados Sumarizados - Parte 3 - Usando Tabelas Externas",
"TEMA": "Nesse novo artigo sobre geração de relatórios com dados sumarizados, o foco é o volume de dados. No cenário que descrevo aqui, o problema é que a base de dados ficou tão grande que nem mesmo a visão indexada consegue oferecer uma performance adequada. Cada empresa tem seu próprio padrão do que é aceitável para o tempo de resposta de um relatório sumarizado, mas é comum aceitarmos respostas na ordem de alguns segundos. Mas quando se passa do limite reconhecido como aceitável, é hora de ligar o alerta. “Houston, temos um problema”!",
"DATA": 43060,
"LINK": "https://imasters.com.br/banco-de-dados/sql-server/consultando-dados-sumarizados-parte-3-indices-columnstore/?trace=1519021197&source=author-archive",
"TAGS": "SUMMARIZE"
}
]
}
Busca de múltiplas palavras
Agora minha pesquisa precisa buscar todos os documentos que contenham palavras específicas (todas elas), independente da ordem. Além disso, quero que o output traga apenas o campo TITULO.
Neste caso, entra uma questão importante que frequentemente causa confusão. É possível fazer pesquisas simples com operadores, por exemplo o AND (que usa o símbolo “+”), OR (“|”) e o NOT (“-”). Mas existe também o parâmetro “searchMode”, que especifica como a pesquisa será realizada.
Por default, o searchMode tem o valor any, ou seja, qualquer palavra da lista que for especificada. Obviamente, este comportamento é o mesmo que observamos com o uso do operador OR.
O detalhe importante aqui é que este parâmetro se sobrepõe aos operadores definidos na pesquisa. Portanto, por default, as buscas retornarão qualquer valor de uma lista, independente se usamos operador OR ou AND.
Experimente executar a pesquisa proposta acima (que usaria operador AND) sem definir o searchMode e observe o resultado.
Resta mencionar como vamos apresentar apenas o campo TITULO. Para isso, inclua o parâmetro $select como penúltimo parâmetro da URL, logo antes da API-VERSION. Observe que a busca é feita sobre documento todo. Mas se apresenta como saída apenas o título do artigo.
A seguir apresento o end-point parametrizado e o resultado obtido.
- Busca 3: Pesquisa das palavras “cruzada” e “ROLLUP”. Resultado traz apenas o campo TITULO
- Endpoint: https://wcrivelini-test1.search.windows.net/indexes/publications/docs?search=rollup+cruzada&searchMode=all&$select=TITULO&api-version=2016-09-01
- Verbo: GET
- Headers (usando chave de consulta): Content-type: application/JSON Api-Key: 4DDB0B46B1CE55768C1A8B062564DAC7
- Authorization: “No Auth”
- Body (raw): Vazio
Body (resultado):
{
"@odata.context": "https://wcrivelini-test1.search.windows.net/indexes('publications')/$metadata#docs(TITULO)",
"value": [
{
"@search.score": 0.9283088,
"TITULO": "Construindo relatórios de referência cruzada no Microsoft SQL SERVER 2005 – Parte 2: Estudo dos operadores PIVOT e ROLLUP"
}
]
}
Comentários finais
A simplicidade de configuração e consumo do serviço do Azure Search são dois pontos altos. Muito fácil preparar sua aplicação para utilizar este serviço.
É verdade que a grande maioria das consultas que realizamos no dia a dia são aquelas que usam recursos básicos como os apresentados aqui. No entanto, o real potencial do Azure Search vai muito além!
No próximo artigo apresentarei recursos avançados de pesquisa disponíveis neste serviço.
Leituras sugeridas
De 0 a 10, o quanto você recomendaria este artigo para um amigo?