Rendimiento de búsqueda de MongoDb

Gracias por publicar la explicación. Abordemos los problemas uno por uno.

Primero, no creo que esta consulta haga lo que crees que hace/quieres que haga. Déjame mostrarte un ejemplo usando el shell mongo. Su consulta, traducida al shell, es

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

Esta consulta encuentra documentos en los que alguna Key tiene el valor "ClientId" y algún Value tiene el valor "xxx" o alguna Key tiene el valor "CustomerName" y algún Value el valor "Jan". La clave y el valor no necesitan ser parte del mismo elemento de matriz . Por ejemplo, el siguiente documento coincide con su consulta

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

Supongo que su comportamiento deseado es hacer coincidir exactamente los documentos que contienen la Key y Value en el mismo elemento de matriz. El $elemMatch operador es la herramienta para el trabajo:

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

En segundo lugar, no creo que este esquema sea lo que está buscando. No describe su caso de uso, por lo que no puedo estar seguro, pero la situación descrita en esa publicación de blog es una situación muy rara en la que necesita almacenar y buscar en arbitrario pares clave-valor que pueden cambiar de un documento a otro. Esto es como dejar que los usuarios introduzcan metadatos personalizados. Casi ninguna aplicación quiere o necesita hacer esto. Parece que su aplicación almacena información sobre los clientes, probablemente para un sistema interno. Debería poder definir un modelo de datos para sus clientes que parece

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

Esto simplificará y mejorará las cosas dramáticamente. Creo que los cables se cruzaron aquí porque a veces la gente llama a MongoDB "sin esquema" y la publicación del blog habla de documentos "sin esquema". La publicación del blog realmente está hablando de documentos sin esquema en los que no sabe qué va a entrar allí. La mayoría de las aplicaciones deberían saber con bastante exactitud cuál será la estructura general de los documentos de una colección.

Finalmente, creo que, sobre la base de esto, podemos ignorar el problema con la consulta lenta por ahora. No dude en hacer otra pregunta o editar esta con una explicación adicional si necesita más ayuda o si el problema no desaparece una vez que haya tenido en cuenta lo que he dicho aquí.