Par exemple, nous avons le champ 1 à 10. Je veux indexer tout le champ dans Azure Search, afin que vous puissiez filtrer, rechercher sur ces filtres.
Ma question est la suivante: existe-t-il un moyen d'exclure simplement les champs qui sont NULL d'un ID spécifique, afin de ne pas les stocker dans la recherche Azure? Voir l'exemple ci-dessous.
Les données elles-mêmes sont initialement stockées dans Azure Cosmos Database. Dans Azure Cosmos DB, cela ressemblerait à ceci:
Cependant, dans Azure Search Index, cela ressemble à ceci:
3 Réponses :
Pour autant que ne pas sauvegarder les valeurs nulles, AFAIK ce n'est pas possible. Un index dans la recherche cognitive a un schéma prédéfini (un peu comme une table de base de données relationnelle) et en fonction du type de données d'un attribut, la valeur d'un attribut sera initialisée avec une valeur par défaut ( null pour la plupart des données types).
C'est dommage .. Disons que vous avez plus de 1000 champs et que vous avez des données comme dans mon exemple, un identifiant ne contient que 10 de ces champs. La seule façon de gagner en efficacité est de les partitionner
Non, ce n'est pas le cas comme l'a expliqué Bruce Johnston.
La réponse la plus courte à votre question est "non", mais c'est un peu plus profond que cela.
Lorsque vous ajoutez des documents à un index de recherche cognitive Azure, les valeurs de chaque champ sont stockées dans une structure de données appelée index inversé . Cela stocke un dictionnaire des termes trouvés dans le champ, et chaque entrée contient une liste d'ID de document contenant ce terme. Il est quelque peu similaire à une base de données orientée colonnes à cet égard. La valeur null que vous voyez dans le document JSON n'est jamais réellement stockée dans l'index inversé. Cela peut rendre coûteux de tester si un champ est nul, car la requête doit rechercher tous les ID de document non contenus dans l'index inversé, mais il est parfaitement efficace en termes de stockage (car il n'en consomme aucun). < / p>
Cet article contient quelques exemples simplifiés du fonctionnement des index inversés, bien qu'il s'agisse d'un sujet différent de celui de votre question.
Votre préoccupation générale concernant la définition de nombreux champs dans votre index est valide. Il existe un compromis entre la flexibilité du schéma et l'utilisation des ressources lorsque vous augmentez le nombre de champs dans votre index. Cependant, cela est dû à la surcharge comptable requise pour chaque champ, et non au "nombre de valeurs nulles dans le champ" (ce qui ne veut vraiment rien dire puisque les valeurs nulles ne sont pas stockées).
D'après votre question, il semble que vous essayez de modéliser différents "types d'entités" dans le même index, ce qui donne un index fragmenté où certains sous-ensembles de documents ont un sous-ensemble de champs définis, tandis qu'un autre sous-ensemble de documents a différents champs définis. C'est un scénario que nous souhaitons mieux accompagner dans le service. Une direction future prometteuse pourrait être la prise en charge des requêtes multi-index, de sorte que chaque sous-ensemble de votre schéma pourrait avoir son propre index avec son propre ensemble de champs distinct (mais peut-être se chevauchant). Ce n'est pas sur notre feuille de route immédiate, mais c'est quelque chose que nous voulons approfondir. Veuillez voter sur cette voix d'utilisateur article pour nous aider à établir des priorités.
Si votre problème concerne le stockage, ce n'est pas un problème puisqu'il s'agit d'un index inversé.
Si vous rencontrez un problème avec la complexité des données JSON renvoyées, vous pouvez implémenter votre propre service intermédiaire qui masque simplement toutes les valeurs NULL du JSON. Ainsi, votre application interroge votre propre service de requête qui à son tour interroge le service Azure réel. Il suffit de transmettre tous les paramètres tels quels. La seule différence est que votre service supprime à la fois la clé / valeur du JSON pour faciliter la gestion des réponses.
La réponse de la recherche semblerait alors être identique à votre enregistrement Cosmos.
Quelle est votre préoccupation spécifique avec les valeurs nulles? Avez-vous besoin de les exclure des résultats de la requête, ou est-ce autre chose?
Eh bien, nous avons plus de 1000 champs sur lesquels nous voulons filtrer ou rechercher. Ma préoccupation est la latence et l'efficacité de la recherche Azure, l'utilisation de la recherche Azure prend plus de temps à cause de ces champs
Ce n'est pas vraiment à cause des valeurs nulles. Il y a une surcharge impliquée avec chaque nouveau champ que vous définissez, quel que soit le nombre de valeurs nulles qu'il "contient" (il ne contient pas vraiment de valeurs nulles, ce que je vais expliquer dans ma propre réponse à cette question). Si vous souhaitez explorer les implications en termes de performances d'avoir de nombreux champs, je vous recommande de publier une question distincte ou de contacter le support client si vous rencontrez des problèmes plus profonds et avez besoin de plus d'engagement que ce que nous pouvons vous donner via StackOverflow.