Este documento descreve as práticas recomendadas para a API Search. Usamos aspas simples (‘") para delimitar strings de consulta. Dessa forma, uma consulta que contém frases com várias palavras entre aspas duplas pode ser delimitada sem confusão: 'field:"some text" some-value'
.
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. Se você quiser excluir esses restaurantes, use 'NOT cuisine:undefined'
como consulta. Porém, é mais caro avaliar dessa forma (em termos de operações faturáveis e tempo de computação) do que fazer o contrário, isto é, encontrar restaurantes com culinária definida. Em vez de ter um campo, "cuisine", você pode usar dois, cuisine
e cuisine_known
, sendo que o último é um campo atômico. Para os restaurantes com culinária definida, configure o primeiro campo como a culinária real e o segundo campo como "yes"
. Para os restaurantes com culinária desconhecida, defina a culinária como ""
(uma string vazia) e cuisine_known
como "no"
. Agora, para encontrar restaurantes com culinária conhecida, gere uma consulta 'cuisine_known:yes'
, que é muito mais rápida do que a negação.
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 'cuisine:Japanese OR cuisine:Korean'
. Uma alternativa é indexar documentos com categorias mais gerais de culinária. Nesse caso, a consulta pode 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'
. Afinal, se a cidade estiver definida como "toronto"
, não poderá ser definida 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. Porém, 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) irá demorar muito. É 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. Depois, sua consulta se tornará '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 os 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
. Em seguida, você poderá encontrar todos os restaurantes que custam 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.