Wenn MongoDB eine Achillesferse hat, dann ist es die Tatsache, dass es nur Single-Threaded Writes und Single-Threaded Map-Reduces unterstützt.
Wie immer gibt es hier Kompromisse. Singlethread-Schreibvorgänge sind die einfachste Möglichkeit, Sperrprobleme zu vermeiden und den Overhead zu minimieren. Auf die gleiche Weise sind Multi-Threaded Map-Reduces eine großartige Möglichkeit, Ihre Daten zu sperren. Single-Threaded Map-Reduces auf einem Produktionssystem sind also wahrscheinlich einfacher und sicherer.
Allerdings sind Sie hier nicht ohne Werkzeuge. MongoDB stellt jeder Instanz einen Schreibthread zur Verfügung. Wenn Sie also MongoDB teilen, erhalten Sie einen Schreib-Thread für jeden Shard.
Wenn Sie mehrere Indizes für 2 Milliarden Zeilen wünschen, sollten Sie sich sowieso Sharding ansehen. Etwas schnelle Mathematik hier:MongoID ist 12 Bytes. Index auf MongoID wird 2B * 12 Bytes =22GB+ sein. Wenn Sie jetzt zwei weitere Indizes hinzufügen möchten (sogar nur zwei 4-Byte-Ganzzahlen), sprechen wir von jeweils 7,5 GB.
Bei 2 Milliarden Zeilen sprechen Sie also von über 37 GB in Indizes (Minimum). ). Auf den meisten 8-Core-Servern bedeutet dies, dass Sie nicht einmal Ihre Indizes im Speicher behalten können, geschweige denn Daten.
Wenn Sie hier also ernsthafte Leistung wünschen, sollten Sie sich mit Sharding befassen. Nur basierend auf den allgemeinen Zahlen. FWIW, MySQL wäre nicht mehr in der Lage, 2B-Dokumente zu verarbeiten. Bei so vielen Daten möchten Sie wirklich, dass mehrere Server mit der Last Schritt halten.
