Wydajność wyszukiwania MongoDb

Dzięki za wysłanie wyjaśnienia. Zajmijmy się problemami pojedynczo.

Po pierwsze, nie sądzę, aby to zapytanie robiło to, co myślisz, że robi / chce, aby zrobiło. Pokażę ci na przykładzie powłoki mongo. Twoje zapytanie przetłumaczone na powłokę to

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

To zapytanie umożliwia znalezienie dokumentów, w których jakiś Key ma wartość "ClientId" i pewną Value ma wartość "xxx" lub jakiś Key ma wartość "CustomerName" i pewną Value wartość „Jan”. Klucz i wartość nie muszą być częścią tego samego elementu tablicy . Na przykład poniższy dokument pasuje do Twojego zapytania

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

Domyślam się, że pożądanym zachowaniem jest dokładne dopasowanie dokumentów zawierających Key i Value w tym samym elemencie tablicy. $elemMatch operator jest narzędziem pracy:

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

Po drugie, nie sądzę, aby ten schemat był tym, czego szukasz. Nie opisujesz swojego przypadku użycia, więc nie mam pewności, ale sytuacja opisana w tym poście na blogu to bardzo rzadka sytuacja, w której musisz przechowywać i wyszukiwać dowolne pary klucz-wartość, które mogą się zmieniać z jednego dokumentu na drugi. To tak, jakby użytkownicy mogli umieszczać niestandardowe metadane. Prawie żadne aplikacje nie chcą lub nie muszą tego robić. Wygląda na to, że Twoja aplikacja przechowuje informacje o klientach, prawdopodobnie dla systemu wewnętrznego. Powinieneś być w stanie zdefiniować model danych dla Twoich klientów, który wygląda jak

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

To znacznie uprości i poprawi sytuację. Myślę, że tutaj przecięto przewody, ponieważ czasami ludzie nazywają MongoDB „bez schematu”, a post na blogu mówi o dokumentach „bez schematu”. Post na blogu naprawdę mówi o dokumentach bez schematu, w których nie wiesz, co się tam znajdzie. Większość aplikacji powinna dokładnie wiedzieć, jaka będzie ogólna struktura dokumentów w kolekcji.

Wreszcie, myślę, że na tej podstawie możemy na razie zignorować problem z powolnym zapytaniem. Jeśli potrzebujesz dodatkowej pomocy lub jeśli problem nie zniknie, gdy weźmiesz pod uwagę to, co tutaj powiedziałem, możesz zadać kolejne pytanie lub zmienić to z dodatkowym wyjaśnieniem.