MongoDb søgeydelse

Tak for at poste forklaringen. Lad os løse problemerne ét ad gangen.

For det første tror jeg ikke, at denne forespørgsel gør, hvad du tror, ​​den gør/ønsker den skal gøre. Lad mig vise dig som eksempel ved at bruge mongo-skallen. Din forespørgsel, oversat til skallen, er

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

Denne forespørgsel finder dokumenter, hvor enten en Key har værdien "ClientId" og en vis Value har værdien "xxx" eller en eller anden Key har værdien "CustomerName" og en vis Value værdien "Jan". Nøglen og værdien behøver ikke at være en del af det samme array-element . For eksempel matcher følgende dokument din forespørgsel

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

Jeg gætter på, at din ønskede adfærd er at matche nøjagtigt de dokumenter, der indeholder Key og Value i samme array-element. $elemMatch operatør er værktøjet til jobbet:

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

For det andet tror jeg ikke, at dette skema er det, du leder efter. Du beskriver ikke din use case, så jeg kan ikke være sikker, men situationen beskrevet i det blogindlæg er en meget sjælden situation, hvor du skal gemme og søge på vilkårlig nøgleværdi-par, der kan ændres fra et dokument til det næste. Det er som at lade brugere indsætte tilpassede metadata. Næsten ingen applikationer ønsker eller behøver at gøre dette. Det ser ud til, at din applikation gemmer oplysninger om kunder, sandsynligvis for et internt system. Du bør være i stand til at definere en datamodel for dine kunder, der ligner

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

Dette vil forenkle og forbedre tingene dramatisk. Jeg tror, ​​at ledningerne er gået over her, fordi folk nogle gange kalder MongoDB "skemaløse", og blogindlægget taler om "skemaløse" dokumenter. Blogindlægget taler virkelig om skemaløse dokumenter, hvor du ikke ved, hvad der skal gå derind. De fleste applikationer burde vide stort set præcis, hvad den generelle struktur af dokumenterne i en samling vil være.

Endelig tror jeg på baggrund af dette, at vi kan se bort fra problemet med den langsomme forespørgsel indtil videre. Stil gerne et andet spørgsmål eller rediger dette med ekstra forklaring, hvis du har brug for mere hjælp, eller hvis problemet ikke forsvinder, når du har taget højde for det, jeg har sagt her.