Es gibt viele Faktoren, die die Exportleistung einschränken.
- Die Datengröße ist im Vergleich zum verfügbaren Arbeitsspeicher relativ groß:~2 TB vs. ~5 GB WiredTiger-Cache (bei Standardeinstellung). Das heißt:
- Der gesamte WiredTiger-Cache kann nur bestenfalls enthalten ~0,22 % der Sammlung, in Wirklichkeit ist es sehr wahrscheinlich viel weniger, da der Cache Daten aus anderen Sammlungen und Indizes enthalten würde.
- Das bedeutet, dass WiredTiger sehr häufig Daten von der Festplatte abrufen muss, während der aktuelle Inhalt des Caches gelöscht wird. Wenn der Replikatsatz aktiv verwendet wird, würde dies bedeuten, dass "schmutzige" Daten aus dem Cache entfernt und auf der Festplatte gespeichert werden, was einige Zeit in Anspruch nehmen würde.
- Beachten Sie, dass Dokumente im WiredTiger-Cache nicht komprimiert werden.
- Die Sammlung enthält große Dokumente, von denen Sie nur einen Teil benötigen. Dies bedeutet, dass zusätzliche Zeit für die Bearbeitung der Dokumente erforderlich ist.
- Die Sammlung ist mit zlib komprimiert, was bedeutet, dass zusätzliche Zeit aufgewendet werden muss, um die Dokumente zu dekomprimieren.
- Die readPreference ist
secondaryPreferred, was bedeutet, dass versucht wird, von einem sekundären zu lesen. Wenn aktiv in den Replikatsatz geschrieben wird, blockieren oplog-Anwendungsvorgänge auf dem sekundären Lesegerät. Dies wird eine weitere Verzögerung hinzufügen.
Eine mögliche Verbesserung besteht darin, bei häufig durchgeführten Vorgängen einen Index für die relevanten Felder zu erstellen und ihn mithilfe eines abgedeckte Abfrage könnte die Leistung verbessern, da der Index kleiner als die vollständigen Dokumente wäre.
Bearbeiten:Ausführen von mongoexport parallel kann in diesem Fall hilfreich sein:
Zusätzlich zu den bereitgestellten zusätzlichen Informationen habe ich einen Test durchgeführt, der dieses Problem etwas zu lindern scheint.
Es scheint, dass mongoexport ausgeführt wird parallel, wo jeder mongoexport Durch die Handhabung einer Teilmenge der Sammlung kann der Export möglicherweise beschleunigt werden.
Teilen Sie dazu die _id Namespace, der der Nummer von mongoexport entspricht Prozess, den Sie ausführen möchten.
Wenn ich zum Beispiel 200.000 Dokumente habe, beginnend mit _id:0 zu _id:199,999 und mit 2 mongoexport Prozesse:
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 &
wobei im obigen Beispiel die beiden mongoexport Prozesse bearbeiten jeweils die Hälfte der Sammlung.
Beim Testen dieses Workflows mit 1 Prozess, 2 Prozessen, 4 Prozessen und 8 Prozessen komme ich zu den folgenden Zeiten:
Verwendung von 1 Prozess:
real 0m32.720s
user 0m33.900s
sys 0m0.540s
2 Prozesse:
real 0m16.528s
user 0m17.068s
sys 0m0.300s
4 Prozesse:
real 0m8.441s
user 0m8.644s
sys 0m0.140s
8 Prozesse:
real 0m5.069s
user 0m4.520s
sys 0m0.364s
Abhängig von den verfügbaren Ressourcen wird 8 mongoexport ausgeführt parallele Prozesse scheinen den Prozess um einen Faktor von ~ 6 zu beschleunigen. Dies wurde in einer Maschine mit 8 Kernen getestet.
Hinweis :Halfers Antwort ist ähnlich, obwohl diese Antwort im Grunde versucht zu sehen, ob es einen Vorteil gibt, mongoexport aufzurufen parallel.
