En este documento, se describen las prácticas recomendadas para la API de Búsqueda. Usamos comillas simples ('') a lo largo de todo el documento para delimitar las strings de consulta. De esta manera, una consulta que contenga frases de varias palabras entre comillas dobles puede delimitarse sin confusión: 'field:"some text" some-value'.
Llamadas Index.delete () y llamadas Index.put () 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 deseas excluir esos restaurantes, podrías usar 'NOT cuisine:undefined' como tu consulta. Sin embargo, esto es más costoso de evaluar (en operaciones facturables y en tiempo de procesamiento) que lo opuesto, encontrar restaurantes cuyas cocinas se conocen. En lugar de tener un campo, cuisine, puedes usar dos, cuisine y cuisine_known, el último de los cuales debe ser un campo atómico. Para los restaurantes cuya cocina está definida, debes establecer el primer campo en la cocina real y el segundo campo en "yes". Para los restaurantes cuya cocina se desconoce, debes establecer cuisine en "" (una string vacía) y cuisine_known en "no". Ahora, para encontrar los restaurantes cuyas cocinas se conocen, debes emitir 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 en operaciones facturables y en tiempo de procesamiento. Supongamos que quieres 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 se puede simplificar a 'cuisine:Asian'.
Elimina las tautologías de tus consultas
Imagina que quieres encontrar todos los restaurantes de Toronto. Supongamos que tus documentos tienen un solo campo llamado “city”, si usas la consulta 'city:toronto AND NOT city:montreal', obtendrás los mismos resultados que 'city:toronto', ya que, si la ciudad se establece en "toronto", no se puede establecer 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. Sin embargo, 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 1,000,000 de documentos.
Usa categorías estrechas para evitar o minimizar el ordenamiento
Si usas el rango para ordenar restaurantes por precio, puedes crear un campo price_range que contenga categorías de precios: price_0_10, price_11_20, price_21_30, price_31_40 y price_41_lots. Luego, puedes encontrar todos los restaurantes que cuesten entre $21 y $40 sin ordenarlos en absoluto mediante la consulta 'price_range:price_21_30 OR price_range:price_31_40'. En muchos casos, las categorías adecuadas no están bien definidas, 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.