Recomendaciones para la búsqueda

Este documento contiene recomendaciones para la API de Search. Usamos comillas simples (‘’) en todo el documento para delimitar las strings de consulta. De esta manera, una consulta que contenga frases de palabras múltiples encerradas en comillas dobles pueden delimitarse sin confusión.‘field:"some text" some-value’.

Usa campos atómicos para datos booleanos

Almacenar datos booleanos en campos numéricos es muy poco eficiente. En cambio, usa campos atómicos y asigna tus constantes favoritas (Verdadero/Falso, sí/no, 0/1).

Convierte negativos en positivos

Imagina que tienes un término especial para identificar los restaurantes cuya cocina no está definida. Si quieres excluir esos restaurantes, podrías usar ‘NOT cuisine:undefined’ como tu consulta. Sin embargo, esto es más costoso de evaluar (tanto en operaciones facturables como en tiempo de procesamiento) que lo opuesto, encontrar restaurantes cuyas cocinas sean conocidas. En lugar de tener un campo, cuisine, puedes usar dos cuisine y cuisine_known, el cual es un campo atómico. Para los restaurantes cuya cocina está definida, configuras el primer campo a la cocina real y el segundo campo a "yes". Para restaurantes en los cuales se desconoce la cocina, configura cuisine en "" (una string vacía) y cuisine_known en "no". Ahora, para encontrar restaurantes cuyas cocinas son conocidas, emites una consulta ‘cuisine_known:yes’, que es mucho más rápida que la negación.

Convierte disyunciones en conjunciones

La disyunción "OR" es una operación costosa tanto en operaciones facturables como en tiempo de procesamiento. Imagina que deseas buscar ‘cuisine:Japanese OR cuisine:Korean’. Una alternativa es indexar los documentos con categorías de cocina más generales. En este caso, la consulta puede simplificarse a ‘cuisine:Asian’.

Elimina las tautologías de tus consultas

Imagina que quieres encontrar todos los restaurantes en Toronto. En el supuesto de que tus documentos tengan solo un campo llamado "ciudad", si usas la consulta ‘city:toronto AND NOT city:montreal’, obtendrás los mismos resultados que ‘city:toronto’ porque si la ciudad se configura en "toronto", no puede configurarse en "montreal". La segunda consulta se ejecuta mucho más rápido, ya que implica solo un término. La primera consulta realiza tres pasos: en primer lugar, encuentra una lista de documentos en los que la ciudad está configurada en "toronto", luego, encuentra una lista de todas las ciudades en las que la ciudad no está configurada en "montreal" y, por último, calcula la intersección de las dos listas.

Limita el rango antes de ordenar

Imagina que tu aplicación almacena información acerca de restaurantes de todo el mundo y te gustaría mostrar los restaurantes más cercanos al usuario actual. Una forma de hacerlo es ordenar los documentos coincidentes según la distancia desde la ubicación del usuario. Pero si tienes 1,000,000 restaurantes, ejecutar una consulta como ‘cuisine:japanese’ con la expresión de ordenamiento distance(geopoint(x, y), restaurant_loc) llevará mucho tiempo. Es conveniente agregar filtros a una consulta, de modo que comiences con un conjunto destacado de documentos seleccionados para ordenar. Una solución es crear categorías geográficas, como país, estado y ciudad; puedes inferir la ciudad y el estado a partir de la ubicación del usuario. Luego, tu consulta se convierte en ‘cuisine:japanese AND city:<user-city>’. Existe una alta probabilidad de que ya no necesites ordenar un millón de documentos.

Usa categorías estrechas para evitar o minimizar el ordenamiento

Si usas la clasificación para ordenar restaurantes por el precio, podrías crear un campo price_range que contenga las categorías de precio: price_0_10, price_11_20, price_21_30, price_31_40, price_41_lots. De ese modo, podrías encontrar todos los restaurantes que cuestan entre $21 y $40 sin ordenar en absoluto con la consulta ‘price_range:price_21_30 OR price_range:price_31_40’. En muchos casos, las categorías adecuadas no son casos claros, pero, con esta técnica, puedes rechazar una gran cantidad de documentos antes de reducir la búsqueda con consultas costosas como ‘... AND price>25 AND price<35’.

No asignes puntuaciones a las coincidencias si no es necesario

Las puntuaciones sirven para indicar qué tan bien coincidió un documento dado con una consulta. Si no vas a usar esa información para ordenar los resultados, no solicites que se asignen puntuaciones. Lo único que lograrás es hacer que la consulta tarde más.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Entorno estándar de App Engine para Go