Práticas recomendadas de pesquisa

Neste documento, apresentamos as práticas recomendadas para a API Search. Usamos aspas simples (‘’) em toda a delimitação de strings de consulta. Dessa forma, uma consulta que contém frases compostas por várias palavras entre aspas duplas pode ser delimitada de forma precisa: ‘field:"some text" some-value’.

Fazer chamadas em lote para Index.put() e Index.delete()

Você pode passar até 200 documentos ao mesmo tempo ao adicioná-los ou exclui-los de um índice. Isso é muito mais eficiente do que manipulá-los um por vez.

Usar a posição do documento para pré-classificar documentos

Por padrão, a pesquisa retorna seus resultados por posição decrescente. Também por padrão, a API Search define a posição de cada documento em segundos, começando em 1º de janeiro de 2011. Assim, os documentos mais recentes são retornados primeiro. No entanto, se você não precisa que os documentos sejam classificados no momento em que são adicionados, você pode usar a posição para outros fins. Imagine que você tenha um aplicativo imobiliário. Os clientes geralmente preferem classificar por preço. Para uma classificação padrão eficiente, defina a posição pelo preço do imóvel.

Se você precisar de várias ordens de classificação, como do menor para o maior preço e do maior para o menor preço, pode criar um índice separado para cada ordem. Um índice teria posição = preço e o outro posição = preço-MAXINT (uma vez que a posição tem que ser positiva).

Usar a posição como a chave de classificação melhora o desempenho da pesquisa. Para especificar outras chaves de classificação, use as opções de classificação, o que limita o número de resultados da pesquisa a 10.000 documentos. Nesse caso, a ordem de classificação determinada pela posição determinará quais documentos serão incluídos na classificação. Leia sobre as opções de classificação para saber mais.

Usar campos atômicos para dados booleanos

Armazenar dados booleanos em campos numéricos é muito ineficiente. Em vez disso, use campos atômicos e atribua suas constantes favoritas (True/False, yes/no, 0/1).

Transformar negativos em positivos

Imagine que você tem um termo especial para identificar restaurantes com culinária indefinida. Para excluir esses restaurantes, você poderia usar ‘NOT cuisine:undefined’ como sua consulta. Contudo, avaliar dessa forma custa mais (em termos de operações faturáveis e tempo de computação) do que fazer o contrário, encontrar restaurantes com culinária definida. Em vez de ter um campo, "cuisine", você pode usar dois, cuisine e cuisine_known, com o último sendo um campo atômico. Para restaurantes cuja culinária é definida, configure o primeiro campo como o tipo de culinária e o segundo campo como "yes". Para restaurantes cujo tipo de culinária é desconhecido, defina "cuisine" como "" (uma string vazia) e cuisine_known como "no". No entanto, para encontrar restaurantes em que a culinária é conhecida, gere uma consulta ‘cuisine_known:yes’, que é muito mais rápida que a negativa.

Transformar disjunções em conjunções

A disjunção "OR" é uma operação dispendiosa tanto em termos de operações faturáveis quanto em termos de tempo de computação. Suponha que você queira pesquisar por ‘cuisine:Japanese OR cuisine:Korean’. Uma alternativa é indexar documentos com categorias mais gerais de culinária. Neste caso, talvez a consulta possa ser simplificada para ‘cuisine:Asian’.

Eliminar tautologias de suas consultas

Imagine que você queira encontrar todos os restaurantes em Toronto. Supondo que seus documentos tenham apenas um único campo chamado "city", se você usar a consulta ‘city:toronto AND NOT city:montreal’ terá os mesmos resultados que ‘city:toronto’. Isso ocorre porque, se a cidade estiver definida como "toronto", não é possível defini-la como "montreal". A segunda consulta é muito mais rápida, porque envolve apenas um termo. A primeira consulta executa três etapas: primeiro encontra uma lista de documentos em que a cidade está definida como "toronto" e, em seguida, encontra uma lista de todas as cidades em que o campo "city" não está definido como "montreal" e, finalmente, calcula a interseção das duas listas.

Limitar o intervalo antes de classificar

Imagine que seu aplicativo armazene informações sobre restaurantes de todo o mundo, e você gostaria de mostrar os restaurantes mais próximos do usuário atual. Uma maneira de fazer isso é classificar os documentos correspondentes pela distância da localização do usuário. Mas se você tiver 1 milhão de restaurantes, executar uma consulta como ‘cuisine:japanese’ com a expressão de classificação distance(geopoint(x, y), restaurant_loc), levará muito tempo. É uma boa ideia adicionar filtros a uma consulta para que você comece com um conjunto mais relevante de documentos selecionados para classificar. Uma solução é criar categorias geográficas, como país, estado e cidade. Você pode inferir a cidade e o estado pela localização do usuário. Desse modo, sua consulta passa a ser ‘cuisine:japanese AND city:<user-city>’. Muito provavelmente, você não precisará mais classificar 1 milhão de documentos.

Usar categorias restritas para evitar ou minimizar a classificação

Se você usar a posição para classificar restaurantes por preço, poderá criar um campo price_range que contenha categorias de preço: price_0_10, price_11_20, price_21_30, price_31_40, price_41_lots. Assim, seria possível encontrar todos os restaurantes com custo entre US$ 21 e US$ 40 sem nenhuma classificação usando a consulta ‘price_range:price_21_30 OR price_range:price_31_40’. Em muitos casos, as categorias apropriadas não são tão claras, mas com essa técnica, é possível rejeitar uma grande quantidade de documentos antes de restringir a pesquisa com consultas caras, como ‘... AND price>25 AND price<35’.

Não pontuar correspondências, a menos que necessário

A pontuação é usada para indicar o nível de correspondência de determinado documento a uma consulta. No entanto, a menos que você pretenda classificar pelo valor da pontuação, não a solicite. Isso só tornará sua pesquisa mais lenta.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Ambiente padrão do App Engine para Python 2