Performances de recherche MongoDb

Merci d'avoir posté l'explication. Réglons les problèmes un par un.

Tout d'abord, je ne pense pas que cette requête fasse ce que vous pensez qu'elle fait / voulez qu'elle fasse. Laissez-moi vous montrer par exemple en utilisant le shell mongo. Votre requête, traduite dans le shell, est

{ "$or" : [
    { "$and" : [
        { "SearchTerms.Key" : "ClientId" }, 
        { "SearchTerms.Value" : "xxx" }
    ]},
    { "$and" : [
        { "SearchTerms.Key" : "CustomerName" },     
        { "SearchTerms.Value" : "Jan" }
    ]}
]}

Cette requête trouve des documents où soit une Key a la valeur "ClientId" et une Value a la valeur "xxx" ou une Key a la valeur "CustomerName" et une certaine Value la valeur "Jan". La clé et la valeur n'ont pas besoin de faire partie du même élément de tableau . Par exemple, le document suivant correspond à votre requête

{ "SearchTerms" : [
        { "Key" : "ClientId", "Value" : 691 }, 
        { "Key" : "banana", "Value" : "xxx" }
    ]
}

Je suppose que votre comportement souhaité est de faire correspondre exactement les documents contenant la Key et Value dans le même élément de tableau. Le $elemMatch l'opérateur est l'outil pour le travail :

{ "$or" : [
    { "SearchTerms" : { "$elemMatch" : { "Key" : "ClientId", "Value" : "xxx" } } },
    { "SearchTerms" : { "$elemMatch" : { "Key" : "CustomerName", "Value" : "Jan" } } }
]}

Deuxièmement, je ne pense pas que ce schéma soit ce que vous recherchez. Vous ne décrivez pas votre cas d'utilisation, donc je ne peux pas être sûr, mais la situation décrite dans cet article de blog est une situation très rare où vous devez stocker et rechercher sur arbitraire des paires clé-valeur qui peuvent changer d'un document à l'autre. Cela revient à laisser les utilisateurs ajouter des métadonnées personnalisées. Presque aucune application ne veut ou n'a besoin de le faire. Il semble que votre application stocke des informations sur les clients, probablement pour un système interne. Vous devriez pouvoir définir un modèle de données pour vos clients qui ressemble

{
    "CustomerId" : 1234,
    "CustomerName" : "Jan",
    "ClientId" : "xpj1234",
    ...
}

Cela simplifiera et améliorera considérablement les choses. Je pense que les fils se sont croisés ici parce que parfois les gens appellent MongoDB "schemales" et le billet de blog parle de documents "schemales". Le billet de blog parle vraiment de documents sans schéma dans lesquels vous ne savez pas ce qui va y entrer. La plupart des applications devraient savoir à peu près exactement quelle sera la structure générale des documents d'une collection.

Enfin, je pense que sur la base de cela, nous pouvons ignorer le problème de la requête lente pour le moment. N'hésitez pas à poser une autre question ou à modifier celle-ci avec des explications supplémentaires si vous avez besoin de plus d'aide ou si le problème ne disparaît pas une fois que vous avez pris en compte ce que j'ai dit ici.