Recomendaciones para la búsqueda

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

Llamadas Index.put () y llamadas Index.delete () por lotes

Puedes usar hasta 200 documentos a la vez cuando los agregas a un índice o los borras de este. Esto es mucho más eficiente que manejarlos uno por uno.

Usar el rango de documentos para ordenarlos previamente

De forma predeterminada, la búsqueda muestra sus resultados por rango descendente. También de forma predeterminada, la API de Búsqueda establece el rango de cada documento en segundos desde el 1 de enero de 2011. Esto da como resultado que los documentos más recientes se muestren primero. Sin embargo, si no necesitas que los documentos se ordenen por la fecha en que se agregaron, puedes usar el rango para otros fines. Supongamos que tienes una aplicación inmobiliaria. Lo que más quieren los clientes es una clasificación por precio. Para un orden predeterminado eficiente, puedes configurar el rango al precio de la casa.

Si necesita varios órdenes de clasificación, como el precio más bajo al más alto y el precio más alto al más bajo, puedes crear un índice separado para cada orden. Un índice tendría la clasificación = precio y el otro el rango = precio MAXINT (ya que el rango debe ser positivo).

Usar el rango como la clave de orden mejorará el rendimiento de búsqueda. Para especificar otras claves de clasificación, debes usar las opciones de clasificación, que limitan la cantidad de resultados de la búsqueda a 10 000 documentos. En este caso, el orden de clasificación determinado por rango determinará qué documentos se incluirán en la clasificación. Lee acerca de las opciones de clasificación para obtener más información.

Usar campos atómicos para datos booleanos

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

Convertir 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, con el último como campo atómico. Para los restaurantes cuya cocina está definida, configuras el primer campo en la cocina real y el segundo campo en "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 cocina es conocida, emites una consulta ‘cuisine_known:yes’, que es mucho más rápida que la negación.

Convertir 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’.

Eliminar las tautologías de tus consultas

Imagina que quieres encontrar todos los restaurantes de 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.

Limitar el rango antes de ordenar

Imagina que tu aplicación almacena información acerca de restaurantes por todo el mundo y que 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 orden 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.

Usar categorías estrechas para evitar o minimizar el orden

Si usas el rango 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 USD 21 y USD 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 claras, 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 en completarse.

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

Enviar comentarios sobre...

Entorno estándar de App Engine para Java 8