Prestazioni di ricerca di MongoDb

Grazie per aver pubblicato la spiegazione. Affrontiamo i problemi uno alla volta.

Innanzitutto, non penso che questa query faccia ciò che pensi che faccia / vuoi che faccia. Lascia che ti mostri con un esempio usando la mongo shell. La tua query, tradotta nella shell, è

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

Questa query trova documenti in cui è presente qualche Key ha il valore "ClientId" e alcuni Value ha il valore "xxx" o qualche Key ha il valore "CustomerName" e alcuni Value il valore "Gen". Non è necessario che la chiave e il valore facciano parte dello stesso elemento dell'array . Ad esempio, il seguente documento corrisponde alla tua richiesta

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

Immagino che il tuo comportamento desiderato sia quello di abbinare esattamente i documenti che contengono la Key e Value nello stesso elemento dell'array. Il $elemMatch operatore è lo strumento per il lavoro:

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

In secondo luogo, non penso che questo schema sia quello che stai cercando. Non descrivi il tuo caso d'uso, quindi non posso essere sicuro, ma la situazione descritta in quel post del blog è una situazione molto rara in cui è necessario archiviare e cercare su arbitrario coppie chiave-valore che possono cambiare da un documento all'altro. È come consentire agli utenti di inserire metadati personalizzati. Quasi nessuna applicazione vuole o ha bisogno di farlo. Sembra che la tua applicazione memorizzi informazioni sui clienti, probabilmente per un sistema interno. Dovresti essere in grado di definire un modello di dati per i tuoi clienti che assomiglia a

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

Ciò semplificherà e migliorerà notevolmente le cose. Penso che i fili siano stati incrociati qui perché a volte le persone chiamano MongoDB "schemaless" e il post sul blog parla di documenti "schemaless". Il post sul blog parla davvero di documenti senza schema in cui non sai cosa andrà a finire lì dentro. La maggior parte delle applicazioni dovrebbe sapere praticamente esattamente quale sarà la struttura generale dei documenti in una raccolta.

Infine, penso che sulla base di ciò possiamo ignorare il problema con la query lenta per ora. Sentiti libero di porre un'altra domanda o modificarla con una spiegazione aggiuntiva se hai bisogno di ulteriore aiuto o se il problema persiste dopo aver preso in considerazione ciò che ho detto qui.