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'.
Usa 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.