Este documento descreve as práticas recomendadas para a API Search. Usamos aspas simples ("'") em todo o lado para delimitar as strings de consulta. Desta forma, uma consulta que contenha expressões com várias palavras entre aspas duplas pode ser delimitada sem confusão:
'field:"some text" some-value'.
Processamento em lote de chamadas Index.put() e Index.delete()
Pode transmitir até 200 documentos de cada vez quando os adiciona ou elimina de um índice. Isto é muito mais eficiente do que processá-los um de cada vez.
Use a classificação de documentos para pré-ordenar documentos
Por predefinição, a pesquisa devolve os resultados por ordem descendente da classificação. Além disso, por predefinição, a API Search define a classificação de cada documento para segundos desde 1 de janeiro de 2011. Isto faz com que os documentos mais recentes sejam devolvidos primeiro. No entanto, se não precisar que os documentos sejam ordenados pela hora em que foram adicionados, pode usar a classificação para outros fins. Suponhamos que tem uma aplicação imobiliária. O que os clientes mais querem é ordenar por preço. Para uma ordenação predefinida eficiente, pode definir a classificação para o preço da casa.
Se precisar de várias ordens de ordenação, como preço do mais baixo para o mais alto e preço do mais alto para o mais baixo, pode criar um índice separado para cada ordem. Um índice teria a classificação = preço e o outro índice teria a classificação = MAXINT-preço (uma vez que a classificação tem de ser positiva).
Usar a classificação como chave de ordenação melhora o desempenho da pesquisa. Para especificar outras chaves de ordenação, tem de usar opções de ordenação, o que limita o número de resultados da pesquisa a 10 000 documentos. Neste caso, a ordem de ordenação determinada pela classificação determina que documentos são incluídos na ordenação. Leia acerca das opções de ordenação para saber mais.
Use campos atom para dados booleanos
Armazenar dados booleanos em campos numéricos é muito ineficiente. Em alternativa, use campos atom e atribua as suas constantes favoritas (verdadeiro/falso, sim/não, 0/1).
Transforme o negativo em positivo
Suponhamos que tem um termo especial para identificar restaurantes cuja cozinha não está definida. Se quiser excluir esses restaurantes, pode usar 'NOT cuisine:undefined' como consulta. No entanto, esta opção é mais cara de avaliar (em termos de operações faturáveis e tempo de computação) do que a opção oposta, que consiste em encontrar restaurantes cuja gastronomia é conhecida. Em vez de ter um campo, cuisine, pode usar dois, cuisine e cuisine_known, sendo o último um campo atom. Para restaurantes cuja cozinha está definida, define o primeiro campo para a cozinha real e o segundo campo para "yes". Para restaurantes cuja gastronomia desconhece, defina a gastronomia como "" (uma string vazia) e cuisine_known como "no". Agora, para encontrar restaurantes cuja gastronomia é conhecida, envia uma consulta 'cuisine_known:yes', que é muito mais rápida do que a negação.
Transforme disjunções em conjunções
A disjunção "OR" é uma operação dispendiosa em termos de operações faturáveis e tempo de computação. Suponhamos que quer pesquisar 'cuisine:Japanese OR cuisine:Korean'. Em alternativa, pode indexar documentos com categorias de cozinha mais gerais. Neste caso, a consulta pode ser simplificada para 'cuisine:Asian'.
Elimine tautologias das suas consultas
Suponha que quer encontrar todos os restaurantes em Toronto. Partindo do princípio de que os seus documentos têm apenas um campo denominado "city", se usar a consulta 'city:toronto AND NOT city:montreal', obtém os mesmos resultados que 'city:toronto', porque se a cidade estiver definida como "toronto", não pode ser definida como "montreal". A segunda consulta é executada muito mais rapidamente, uma vez que envolve apenas um termo. A primeira consulta executa três passos: primeiro, encontra uma lista de documentos em que a cidade está definida como "toronto", depois encontra uma lista de todas as cidades em que a cidade não está definida como "montreal" e, finalmente, calcula a interseção das duas listas.
Restrinja o intervalo antes de ordenar
Suponhamos que a sua aplicação armazena informações sobre restaurantes em todo o mundo e quer mostrar os restaurantes mais próximos do utilizador atual. Uma forma de o fazer é ordenar os documentos correspondentes pela distância da localização do utilizador. No entanto, se tiver 1 000 000 de restaurantes, a execução de uma consulta como 'cuisine:japanese' com a expressão de ordenação distance(geopoint(x, y), restaurant_loc) vai demorar muito tempo. É uma boa ideia adicionar filtros a uma consulta para começar com um conjunto mais proeminente de documentos selecionados para ordenar. Uma solução é criar categorias geográficas, como país, distrito e cidade. Pode inferir a cidade e o distrito a partir da localização do utilizador. Em seguida, a sua consulta torna-se 'cuisine:japanese AND city:<user-city>'. É muito provável que já não precise de ordenar 1 000 000 de documentos.
Use categorias restritas para evitar ou minimizar a ordenação
Se usar a classificação para ordenar restaurantes por preço, pode criar um campo price_range que contenha categorias de preços: price_0_10, price_11_20, price_21_30, price_31_40 e price_41_lots. Em seguida, pode encontrar todos os restaurantes com um custo entre 21 e 40 € sem qualquer ordenação através da consulta 'price_range:price_21_30 OR price_range:price_31_40'. Em muitos casos, as categorias adequadas não são tão claras, mas com esta técnica pode rejeitar um grande número de documentos antes de reduzir a pesquisa com consultas dispendiosas, como '... AND price>25 AND price<35'.
Não atribua pontuações às partidas, a menos que seja necessário
A pontuação é usada para indicar o nível de correspondência de um determinado documento com uma consulta. No entanto, a menos que pretenda ordenar por pontuação, não peça a classificação. Só vai tornar a sua pesquisa mais lenta.