Obrigado por postar a explicação. Vamos resolver os problemas um de cada vez.
Primeiro, não acho que essa consulta faça o que você acha que faz/quer que faça. Deixe-me mostrar-lhe por exemplo usando o shell mongo. Sua consulta, traduzida no shell, é
{ "$or" : [
{ "$and" : [
{ "SearchTerms.Key" : "ClientId" },
{ "SearchTerms.Value" : "xxx" }
]},
{ "$and" : [
{ "SearchTerms.Key" : "CustomerName" },
{ "SearchTerms.Value" : "Jan" }
]}
]}
Esta consulta encontra documentos onde alguma
Key tem o valor "ClientId" e algum Value tem o valor "xxx" ou alguma Key tem o valor "CustomerName" e algum Value o valor "Jan". A chave e o valor não precisam fazer parte do mesmo elemento de array . Por exemplo, o seguinte documento corresponde à sua consulta { "SearchTerms" : [
{ "Key" : "ClientId", "Value" : 691 },
{ "Key" : "banana", "Value" : "xxx" }
]
}
Acho que o comportamento desejado é corresponder exatamente aos documentos que contêm a
Key e Value no mesmo elemento da matriz. O $elemMatch
operador é a ferramenta para o trabalho:{ "$or" : [
{ "SearchTerms" : { "$elemMatch" : { "Key" : "ClientId", "Value" : "xxx" } } },
{ "SearchTerms" : { "$elemMatch" : { "Key" : "CustomerName", "Value" : "Jan" } } }
]}
Segundo, não acho que esse esquema seja o que você está procurando. Você não descreve seu caso de uso, então não posso ter certeza, mas a situação descrita nessa postagem do blog é uma situação muito rara em que você precisa armazenar e pesquisar em arbitrário pares chave-valor que podem mudar de um documento para outro. Isso é como permitir que os usuários insiram metadados personalizados. Quase nenhum aplicativo quer ou precisa fazer isso. Parece que seu aplicativo está armazenando informações sobre clientes, provavelmente para um sistema interno. Você deve ser capaz de definir um modelo de dados para seus clientes que parece
{
"CustomerId" : 1234,
"CustomerName" : "Jan",
"ClientId" : "xpj1234",
...
}
Isso simplificará e melhorará as coisas drasticamente. Acho que os fios se cruzaram aqui porque às vezes as pessoas chamam o MongoDB de "sem esquema" e a postagem do blog fala sobre documentos "sem esquema". A postagem do blog realmente está falando sobre documentos sem esquema em que você não sabe o que vai entrar lá. A maioria dos aplicativos deve saber exatamente qual será a estrutura geral dos documentos em uma coleção.
Finalmente, acho que com base nisso podemos desconsiderar o problema com a consulta lenta por enquanto. Sinta-se à vontade para fazer outra pergunta ou editar esta com uma explicação extra se precisar de mais ajuda ou se o problema não desaparecer depois de levar em consideração o que eu disse aqui.
