Ce document décrit les bonnes pratiques de l'API Search. Nous utilisons ici des guillemets simples (‘’) pour délimiter les chaînes de requête. De cette manière, lorsqu'une requête contient des expressions de plusieurs mots entourées de guillemets doubles, elle peut être délimitée sans confusion : 'field:"some text" some-value'.
Utilisez des champs atomiques pour les données booléennes
Le stockage de données booléennes dans des champs numériques est une méthode très inefficace. Utilisez plutôt des champs atomiques et affectez les constantes de votre choix ("True/False", "yes/no", 0/1).
Transformez les négatifs en positifs
Supposons que vous ayez un terme spécial pour identifier les restaurants dont le type de cuisine n'est pas défini. Si vous souhaitez exclure ces restaurants, vous pouvez utiliser 'NOT cuisine:undefined' comme requête. Ce type d'évaluation est plus coûteux (en matière d'opérations facturables et de temps de calcul) que l'évaluation contraire, à savoir rechercher les restaurants dont le type de cuisine est défini. Plutôt que d'avoir un seul champ, la cuisine, vous pouvez en utiliser deux, cuisine et cuisine_known, le dernier étant un champ Atom. Pour les restaurants dont le type de cuisine est défini, vous définissez alors le premier champ sur le type de cuisine concerné, et le second sur "yes". Pour les restaurants dont vous ne connaissez pas le type de cuisine, vous définissez "cuisine" sur "" (chaîne vide) et cuisine_known sur "no". Pour trouver à présent des restaurants dont le type de cuisine est défini, lancez une requête 'cuisine_known:yes', beaucoup plus rapide que la négation.
Transformez les disjonctions en conjonctions
La disjonction "OR" est une opération coûteuse à la fois en opérations facturables et en temps de calcul. Supposons que vous souhaitiez rechercher 'cuisine:Japanese OR cuisine:Korean'. L'idée est alors d'indexer les documents à l'aide de types de cuisine plus généraux. Dans ce cas, la requête peut être simplifiée en 'cuisine:Asian'.
Éliminez les tautologies de vos requêtes
Supposons que vous souhaitiez trouver tous les restaurants de Toronto. En partant du principe que vos documents ne contiennent qu'un seul champ nommé "city", si vous utilisez la requête 'city:toronto AND NOT city:montreal', vous obtenez les mêmes résultats qu'avec la requête 'city:toronto'. En effet, si la ville est définie sur "toronto", elle ne peut pas être définie sur "montreal". La deuxième requête s'exécute beaucoup plus rapidement, car elle n'implique qu'un seul terme. La première requête réalise trois étapes. Premièrement, elle trouve la liste des documents dans lesquels le champ "city" est défini sur "toronto". Deuxièmement, elle trouve la liste de toutes les villes pour lesquelles le champ "city" n'est pas défini sur "montreal". Enfin, elle calcule l'intersection des deux listes.
Appliquez une restriction sur la plage avant le tri
Supposons que votre application stocke des informations sur des restaurants du monde entier, et que vous souhaitiez afficher les restaurants les plus proches de l'utilisateur actuel. Pour cela, vous pouvez trier les documents correspondants en fonction de la distance qui les sépare de l'emplacement de l'utilisateur. Toutefois, si vous avez 1 000 000 de restaurants à trier, lancer une requête du type 'cuisine:japanese' avec l'expression de tri distance(geopoint(x, y), restaurant_loc) prendra beaucoup de temps. Nous vous recommandons d'ajouter des filtres à une requête, pour commencer avec un ensemble des principaux documents à trier. Une solution consiste à créer des catégories géographiques, telles que le pays, l'État et la ville. Vous pouvez déduire la ville et l'État à partir de l'emplacement de l'utilisateur. Votre requête devient alors 'cuisine:japanese AND city:<user-city>'. Il est très probable alors que vous n'ayez plus besoin de trier 1 000 000 de documents.
Utilisez des catégories restreintes pour éviter ou minimiser le tri
Si vous utilisez le classement pour trier les restaurants par prix, vous pouvez créer un champ price_range contenant les catégories de prix suivantes : price_0_10, price_11_20, price_21_30, price_31_40 et price_41_lots. Vous pouvez ensuite trouver tous les restaurants dont les prix sont compris entre 21 $ et 40 $ sans aucun tri, à l'aide de la requête 'price_range:price_21_30 OR price_range:price_31_40'. Dans de nombreux cas, les catégories appropriées ne sont pas aussi bien définies. Toutefois, avec cette technique, vous pouvez exclure un grand nombre de documents avant de lancer la recherche avec des requêtes coûteuses telles que '... AND price>25 AND price<35'.
N'attribuez pas de note aux correspondances, sauf si nécessaire
La notation est utilisée pour indiquer la mesure dans laquelle un document donné correspond à une requête. Toutefois, à moins que vous n'ayez l'intention de trier les documents par note, ne demandez pas leur notation. Cette étape ne ferait que ralentir votre recherche.