Es ist schwer zu sagen, was die optimale Massenbeilage ist – dies hängt teilweise von der Größe der einzufügenden Objekte und anderen unermesslichen Faktoren ab. Sie könnten ein paar Bereiche ausprobieren und sehen, was Ihnen die beste Leistung bringt. Als Alternative verwenden einige Leute gerne mongoimport, was ziemlich schnell ist, aber Ihre Importdaten müssen json oder csv sein. Es gibt offensichtlich mongodrestore, wenn die Daten im BSON-Format vorliegen.
Mongo kann problemlos Milliarden von Dokumenten verarbeiten und kann Milliarden von Dokumenten in einer einzigen Sammlung haben, aber denken Sie daran, dass Die maximale Dokumentgröße beträgt 16 MB . Es gibt viele Leute mit Milliarden von Dokumenten in MongoDB und es gibt viele Diskussionen darüber im MongoDB-Google-Benutzergruppe . Hier ist ein Dokument auf die Verwendung einer großen Anzahl von Sammlungen, die Sie vielleicht lesen möchten, wenn Sie Ihre Meinung ändern und stattdessen mehrere Sammlungen haben möchten. Je mehr Sammlungen Sie haben, desto mehr Indizes werden Sie auch haben, was wahrscheinlich nicht das ist, was Sie wollen.
Hier ist eine Präsentation von Craigslist über das Einfügen von Milliarden von Dokumenten in MongoDB und den Blogpost .
Es sieht so aus, als wäre Sharding eine gute Lösung für Sie, aber typischerweise wird Sharding zum Skalieren über mehrere Server hinweg verwendet, und viele Leute tun dies, weil sie ihre Schreibvorgänge skalieren möchten oder nicht in der Lage sind, ihren Arbeitssatz (Daten und Indizes) beizubehalten. im Arbeitsspeicher. Es ist absolut vernünftig, mit einem einzelnen Server zu beginnen und dann auf einen Shard oder Replikatsatz umzusteigen, wenn Ihre Daten wachsen oder Sie zusätzliche Redundanz und Ausfallsicherheit benötigen.
Es gibt jedoch andere Benutzer, die mehrere Mongods verwenden, um die Sperrgrenzen eines einzelnen Mongods mit vielen Schreibvorgängen zu umgehen. Es ist offensichtlich, aber dennoch erwähnenswert, aber ein Multi-Mongod-Setup ist komplexer zu verwalten als ein einzelner Server. Wenn Ihr IO oder Ihre CPU hier nicht ausgereizt ist, Ihr Arbeitssatz kleiner als der Arbeitsspeicher ist und Ihre Daten leicht im Gleichgewicht zu halten sind (ziemlich zufällig verteilt), sollten Sie eine Verbesserung sehen (mit Sharding auf einem einzelnen Server). Als FYI gibt es Potenzial für Speicher- und IO-Konflikte. Mit 2.2 wurde die Parallelität verbessert mit db sperren , vermute ich, dass es für einen solchen Einsatz viel weniger Gründe geben wird.
Sie müssen Ihren Wechsel zum Sharding richtig planen, d. h. sorgfältig über die Wahl Ihres Shard-Schlüssels nachdenken. Wenn Sie diesen Weg gehen, ist es am besten, den Balancer vorab zu teilen und auszuschalten. Es ist kontraproduktiv, Daten zu verschieben, um die Dinge im Gleichgewicht zu halten, was bedeutet, dass Sie im Voraus entscheiden müssen, wie Sie sie aufteilen. Außerdem ist es manchmal wichtig, Ihre Dokumente so zu gestalten, dass einige Felder für das Sharding oder als Primärschlüssel nützlich sind.
Hier sind einige gute Links -
- Auswählen eines Shard-Schlüssels
- Blogbeitrag zu Shard-Keys
- Überblick über Sharding
- Präsentation zu Best Practices für Sharding
