Misforståelser
Hastighed
Selv når man ikke taler om et multinøgleindeks, er det her, der sker. Der er en massiv bordscanning i gang. Så mongoDB itererer over dokumenterne, forsøger at finde det felt, der skal indekseres, evaluerer det felt (til null hvis det ikke findes i det aktuelle dokument) og skriver dets resultater til ikke mindre end 6 filer, da vi taler om 6 indekser. Regnestykket:200.000.000 / 86400 * 5 fortæller os, at mongoDB gør dette for ca. 460 dokumenter pr. sekund eller behøver kun 2,2 millisekunder pr. dokument . Det vil jeg ikke kalde langsom. Det kan tage lang tid, men det er ikke langsomt.
{background:true}
Brug af denne parameter ikke låse dig ude af databaserne. Tværtimod, hvilket tydeligt fremgår af dokumenterne, både på Sektionen Oprettelse af indeks og i selvstudieafsnittet om oprettelse af indekser i baggrunden . Der er dog en sætning, som let kan misfortolkes:
Hvad det betyder er, at du ikke kan udføre operationer, der gælder for alle databaser og kræver en læse- eller skrivelås.
Måder at forbedre (i fremtiden)
Sharded Cluster
Brug en delt klynge med replika-skår. Det er nemt at sætte op og har flere fordele udover forbedret ydeevne. En af dem er nem skalerbarhed at tilføje et shard (og dermed tilføje plads og computerkraft til en klynge) er meget let. Sikkerhedskopier har mindre indflydelse på applikationen. Der er ikke længere et enkelt fejlpunkt (når det gøres rigtigt, gælder dette endda udfald på størrelse med et helt datacenter).
Brug et andet filsystem
Beklager, at køre et disk io-ydeevneafhængigt program på en Windows Server giver ikke mening for mig - overhovedet. ExtFS4 eller XFS er mellem 25% og 40% hurtigere end NTFS eller ReFS, afhængigt af optimeringen. Dette gør en rigtig forskel på applikationer, der er lige så disk-IO-afhængige som din use case. Vi taler om et spørgsmål om dage (uden at tage højde for den mere effektive hukommelseskortlægning og det reducerede hukommelsesforbrug af operativsystemet på Linux-systemer).
{background:true}
Selvom dette ikke virkelig forbedrer ydeevnen (det tager faktisk længere tid at bygge indekser i baggrunden af indlysende årsager), men din applikation forbliver tilgængelig i det tidsrum, hvor indekset er opbygget. Så afhængigt af dine behov kan dette være en levedygtig mulighed.
Sidebemærkning :Det er en Bad Idea™ , for at skalere lodret, når du bruger mongoDB, da det eksplicit var designet til at blive skaleret vandret. Dette gælder især for store samlinger som din, da parallel behandling i høj grad ville forbedre din applikations ydeevne.