Der er mange faktorer, der begrænser eksportydelsen.
- Datastørrelsen er relativt stor sammenlignet med tilgængelig hukommelse:~2 TB vs. ~5 GB WiredTiger-cache (hvis indstillet til standard). Det vil sige:
- Hele WiredTiger-cachen kan kun indeholde i bedste fald ~0,22 % af samlingen, i virkeligheden er det meget sandsynligt meget mindre end dette, da cachen ville indeholde data fra andre samlinger og indekser.
- Dette betyder, at WiredTiger er nødt til at hente fra disk meget ofte, mens det aktuelle indhold af cachen fjernes. Hvis replikasættet bruges aktivt, vil det betyde, at "beskidte" data fjernes fra cachen og overføres til disken, hvilket ville tage tid.
- Bemærk, at dokumenter inde i WiredTiger-cachen ikke komprimeres.
- Samlingen indeholder store dokumenter, hvoraf du kun behøver en del af den. Det betyder, at der kræves ekstra tid til at behandle dokumenterne.
- Samlingen er komprimeret med zlib, hvilket betyder, at der skal bruges ekstra tid på at komprimere dokumenterne.
- ReadPreference er
secondaryPreferred, hvilket betyder, at den vil forsøge at læse fra en sekundær. Hvis replikasættet bliver skrevet aktivt til, vil oplog-anvendelsesoperationer på den sekundære blokere læsere. Dette vil tilføje yderligere forsinkelse.
En mulig forbedring er, at hvis dette er en operation, du ofte udfører, skal du oprette et indeks på de relevante felter og eksportere det ved hjælp af en dækket forespørgsel kunne forbedre ydeevnen, da indekset ville være mindre end de fulde dokumenter.
Rediger:Kører mongoexport parallelt kan være nyttigt i dette tilfælde:
Ud over de yderligere oplysninger, der er givet, kørte jeg en test, der ser ud til at afhjælpe dette problem noget.
Det ser ud til at køre mongoexport parallelt, hvor hver mongoexport håndtering af en delmængde af samlingen kan muligvis fremskynde eksporten.
For at gøre dette skal du dividere _id navneområde svarende til antallet af mongoexport proces, du planlægger at køre.
For eksempel, hvis jeg har 200.000 dokumenter, startende med _id:0 til _id:199,999 og ved at bruge 2 mongoexport processer:
mongoexport -q '{"_id":{"$gte":0, "$lt":100000}}' -d test -c test > out1.json &
mongoexport -q '{"_id":{"$gte":100000, "$lt":200000}}' -d test -c test > out2.json &
hvor i ovenstående eksempel de to mongoexport processer håndterer hver halvdelen af samlingen.
Ved at teste denne arbejdsgang med 1 proces, 2 processer, 4 processer og 8 processer kommer jeg frem til følgende tidspunkter:
Bruger 1 proces:
real 0m32.720s
user 0m33.900s
sys 0m0.540s
2 processer:
real 0m16.528s
user 0m17.068s
sys 0m0.300s
4 processer:
real 0m8.441s
user 0m8.644s
sys 0m0.140s
8 processer:
real 0m5.069s
user 0m4.520s
sys 0m0.364s
Afhængigt af de tilgængelige ressourcer, kører 8 mongoexport parallelle processer ser ud til at fremskynde processen med en faktor på ~6. Dette blev testet i en maskine med 8 kerner.
Bemærk :halfers svar er ens i idéen, selvom dette svar dybest set forsøger at se, om der er nogen fordel ved at ringe til mongoexport parallelt.