Grundlegendes zur Größenbeschränkung für MongoDB BSON-Dokumente

Aus MongoDB Der endgültige Leitfaden:

Dokumente, die größer als 4 MB sind (bei Konvertierung in BSON), können nicht in der Datenbank gespeichert werden. Dies ist eine etwas willkürliche Grenze (und kann in Zukunft angehoben werden); Dies dient hauptsächlich dazu, ein schlechtes Schemadesign zu verhindern und eine konsistente Leistung sicherzustellen.

Ich verstehe diese Grenze nicht. Bedeutet dies, dass ein Dokument, das einen Blog-Beitrag mit vielen Kommentaren enthält, die zufällig größer als 4 MB sind, nicht als einzelnes Dokument gespeichert werden kann?

Zählt dies auch die verschachtelten Dokumente?

Was wäre, wenn ich ein Dokument wollte, das die Änderungen an einem Wert überprüft? (Es kann schließlich wachsen und die 4-MB-Grenze überschreiten.)

Hoffe jemand erklärt das richtig.

Ich habe gerade angefangen, über MongoDB zu lesen (erste NOSQL-Datenbank, über die ich lerne).

Danke dir.

Zunächst einmal wird dies tatsächlich in der nächsten Version von 8MBoder 16MB... angesprochen, aber ich denke, um dies ins rechte Licht zu rücken, bringt Eliot von 10gen (der MongoDB entwickelt hat) es am besten auf den Punkt:

EDIT: Die Größe wurde offiziell auf erhöht16MB

In Ihrem Blog-Beispiel sind 4 MB also tatsächlich eine ganze Menge. Zum Beispiel ist der vollständige unkomprimierte Text von "War of the Worlds" nur 364 KB (html): http://www.gutenberg.org/etext/36

Wenn dein Blog-Beitrag so lang ist und so viele Kommentare enthält, werde ich ihn nicht lesen :)

Wenn Sie für Trackbacks 1 MB zugewiesen haben, können Sie leicht mehr als 10.000 (wahrscheinlich näher an 20.000) haben.

Abgesehen von wirklich bizarren Situationen wird es also großartig funktionieren. Und im Ausnahmefall oder bei Spam glaube ich wirklich nicht, dass Sie sowieso ein 20-MB-Objekt möchten. Ich denke, dass es sehr sinnvoll ist, Trackbacks auf etwa 15.000 zu begrenzen, unabhängig von der Leistung. Oder zumindest ein spezielles Gehäuse, falls es jemals passieren sollte.

-Eliot

Ich denke, es wird Ihnen ziemlich schwer fallen, das Limit zu erreichen ... und im Laufe der Zeit müssen Sie sich immer weniger Sorgen machen, wenn Sie ein Upgrade durchführen.

Der Hauptpunkt des Limits besteht darin, dass Sie nicht den gesamten Arbeitsspeicher Ihres Servers verbrauchen (da Sie das gesamte MBDokument bei der Abfrage in den Arbeitsspeicher laden müssen ).

Das Limit liegt also bei einigen Prozent des normal nutzbaren Arbeitsspeichers auf einem gemeinsamen System ... der von Jahr zu Jahr weiter wachsen wird.

Hinweis zum Speichern von Dateien in MongoDB

Wenn Sie Dokumente (oder Dateien) speichern müssen, die größer sind als 16MBSie, können Sie die GridFS-API verwenden, die die Daten automatisch in Segmente aufteilt und an Sie zurücksendet (wodurch das Problem mit Größenbeschränkungen / RAM vermieden wird).

Anstatt eine Datei in einem einzelnen Dokument zu speichern, unterteilt GridFS die Datei in Teile oder Blöcke und speichert jeden Block als separates Dokument.

GridFS verwendet zwei Sammlungen zum Speichern von Dateien. Eine Sammlung speichert die Dateiblöcke und die andere speichert Dateimetadaten.

Mit dieser Methode können Sie Bilder, Dateien, Videos usw. in der Datenbank speichern, ähnlich wie in einer SQL-Datenbank. Ich habe dies sogar verwendet, um Multi-Gigabyte-Videodateien zu speichern.

Viele in der Community würden keine Begrenzung mit Warnungen bezüglich der Leistung bevorzugen. In diesem Kommentar finden Sie ein gut begründetes Argument: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin. system.issuetabpanels: comment-tabpanel # comment-22283

Meiner Meinung nach sind die leitenden Entwickler in Bezug auf dieses Problem hartnäckig, weil sie frühzeitig entschieden haben, dass es ein wichtiges "Feature" ist. Sie werden es nicht so schnell ändern, weil ihre Gefühle verletzt sind, dass jemand es in Frage gestellt hat. Ein weiteres Beispiel für Persönlichkeit und Politik, die ein Produkt in Open-Source-Communities beeinträchtigen, ist jedoch kein wirklich lähmendes Problem.

Um hier eine Klarstellungsantwort für diejenigen zu posten, die hier von Google geleitet werden.

Die Dokumentgröße umfasst alles im Dokument, einschließlich der Unterdokumente, verschachtelten Objekte usw.

Also ein Dokument von:

{
    _id:{},
    na: [1,2,3],
    naa: [
        {w:1,v:2,b:[1,2,3]},
        {w:5,b:2,h:[{d:5,g:7},{}]}
    ]
}

Hat eine maximale Größe von 16meg.

Sbudocuments und verschachtelte Objekte werden alle auf die Größe des Dokuments angerechnet.

Ich habe noch kein Problem mit dem Limit gesehen, bei dem keine großen Dateien im Dokument selbst gespeichert waren. Es gibt bereits eine Vielzahl von Datenbanken, die beim Speichern / Abrufen großer Dateien sehr effizient sind. Sie werden als Betriebssysteme bezeichnet. Die Datenbank existiert als Schicht über dem Betriebssystem. Wenn Sie aus Leistungsgründen eine NoSQL-Lösung verwenden, warum sollten Sie dem Zugriff auf Ihre Daten zusätzlichen Verarbeitungsaufwand hinzufügen, indem Sie die DB-Schicht zwischen Ihrer Anwendung und Ihren Daten platzieren?

JSON ist ein Textformat. Wenn Sie also über JSON auf Ihre Daten zugreifen, gilt dies insbesondere, wenn Sie über Binärdateien verfügen, da diese in Uuencode, Hexadezimal oder Base 64 codiert werden müssen. Der Konvertierungspfad sieht möglicherweise so aus

Binärdatei <> JSON (codiert) <> BSON (codiert)

Es wäre effizienter, den Pfad (URL) zur Datendatei in Ihrem Dokument einzufügen und die Daten selbst binär zu halten.

Wenn Sie diese Dateien mit unbekannter Länge wirklich in Ihrer Datenbank behalten möchten, sollten Sie sie wahrscheinlich besser in GridFS einfügen und nicht riskieren, Ihre Parallelität zu beenden, wenn auf die großen Dateien zugegriffen wird.

Verschachtelte Tiefe für BSON-Dokumente: MongoDB unterstützt nicht mehr als 100 Verschachtelungsebenen für BSON-Dokumente.

Mehr mehr Info vist

Vielleicht einen Blogeintrag zu speichern -> Kommentare Beziehung in einer nicht-relationalen Datenbank ist nicht wirklich das beste Design.

Sie sollten Kommentare wahrscheinlich sowieso in einer separaten Sammlung für Blog-Beiträge speichern.

[bearbeiten]

Weitere Kommentare finden Sie in den Kommentaren unten.

Laut https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1

Wenn Sie erwarten, dass ein Blog-Beitrag das 16-MB-Dokumentlimit überschreitet, sollten Sie die Kommentare in eine separate Sammlung extrahieren, auf den Blog-Beitrag aus dem Kommentar verweisen und einen Join auf Anwendungsebene durchführen.

// posts
[
  {
    _id: ObjectID('AAAA'),
    text: 'a post',
    ...
  }
]

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]