Verständnis MongoDB BSON Dokumentgrößenbeschränkung

StackOverflow https://stackoverflow.com/questions/4667597

  •  10-10-2019
  •  | 
  •  

Frage

Von MongoDB The Definitive Guide:

Dokumente, die größer als 4 MB (wenn zu BSON umgewandelt) kann nicht sein, in der Datenbank gespeichert. Dies ist eine etwas willkürliche Grenze (und kann sein in der Zukunft erhöht); es ist meist schlecht Schema-Design zu verhindern und sicherzustellen, konstante Leistung.

Ich verstehe nicht, diese Grenze, bedeutet das, dass ein Dokument eine Blog-Post mit einer Menge von Bemerkungen, die gerade passiert, so dass sie größer als 4 MB können nicht als ein einziges Dokument gespeichert werden?

Auch ist dies auch die verschachtelten Dokumente zählen?

Was passiert, wenn ich ein Dokument gesucht, die die Änderungen auf einen Wert prüft. (Es wird kann schließlich wachsen, 4MB Grenze zu überschreiten.)

Hope jemand erklärt dies richtig.

Ich habe gerade Lesung begann, über MongoDB (erste NoSQL Datenbank Ich lerne über).

Danke.

War es hilfreich?

Lösung

Zunächst einmal, dies ist eigentlich in der nächsten Version 8MB oder 16MB angehoben wird ... aber ich denke, das ist zu relativieren, Eliot von 10gen (die entwickelte MongoDB) setzt es am besten:

EDIT: Die Größe hat offiziell 'angehoben' zu 16MB

Also, auf Ihrem Blog Beispiel 4 MB sind eigentlich eine ganze Menge .. Zum Beispiel, die volle dekomprimiert Text von „War of die Welten“ist nur 364K (html): http://www.gutenberg.org/etext/36

Wenn Ihre Blog-Post ist, dass lange mit dass viele Kommentare ein, ich bin nicht geht es zu lesen:)

Für Trackbacks, wenn Sie 1MB gewidmet zu ihnen, könnte man leicht mehr als 10k (wahrscheinlich näher an 20k)

Ausgenommen, für wirklich bizarr Situationen, es wird großartig arbeiten. Und in der Ausnahmefall oder Spam, mich wirklich glaube nicht, dass Sie ein 20-MB-Objekt wollen würden wie auch immer. Ich denke, Capping Trackbacks als 15k oder macht so viel Sinn kein egal, was für die Leistung. Oder bei dest spezielles Gehäuse, wenn es jemals geschieht.

-Eliot

ich glaube, Sie ziemlich schwer tun, würden die Grenze zu erreichen ... und im Laufe der Zeit, wenn Sie ein Upgrade ... Sie werden zur Sorge haben immer weniger.

Der Hauptpunkt der Grenze ist, so dass Sie alle den RAM auf dem Server aufbrauchen nicht (wie Sie alle MBs des Dokuments in den Arbeitsspeicher geladen werden müssen, wenn Sie es abfragen.)

So ist die Grenze einige% der normalen nutzbaren RAM auf einem gemeinsamen System ..., die für Jahr wächst Jahr halten wird.

Hinweis auf Speichern von Dateien in MongoDB

Wenn benötigen Sie speichern Dokumente (oder Dateien) größer als 16MB Sie die GridFS API welche automatisch die Daten in Segmente aufzubrechen und streamen sie zurück zu Ihnen (und damit das Problem mit Größenbeschränkungen / RAM zu vermeiden.)

Anstatt eine Datei in einem einzigen Dokument zu speichern, GridFS Dividiert die Datei in Teile oder Stücke, und speichert jeden Chunk als separates Dokument.

GridFS verwendet zwei Sammlungen zu speichern Dateien. Eine Sammlung speichert die Datei Chunks und die andere speichert Datei-Metadaten.

Sie kann diese Methode zum Speichern von Bildern verwenden, Dateien, Videos, etc. in der Datenbank viel, wie Sie vielleicht in einer SQL-Datenbank. Ich habe dies verwendet, um sogar Multi-Gigabyte-Video-Dateien zu speichern.

Andere Tipps

Viele in der Gemeinschaft hätten keine Grenze mit Warnungen über die Leistung bevorzugen, finden Sie diesen Kommentar für 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

Meine Meinung ist der Lead-Entwickler zu diesem Problem stur, weil sie beschlossen, es war ein wichtiges „Feature“ frühzeitig zu erkennen. Sie sind es nicht jederzeit ändern würde bald, weil ihre Gefühle verletzt werden, dass es jeder in Frage gestellt. Ein weiteres Beispiel für Persönlichkeit und Politik aus einem Produkt in Open-Source-Communities zu schmälern, aber das ist nicht wirklich eine lähmende Thema.

eine Klarstellung schreiben Antwort hier für diejenigen, die von Google hier gerichtet bekommen.

Die Dokumentgröße enthält alles, was in dem Dokument einschließlich der Teildokumente, verschachtelte Objekte etc.

So ein Dokument: 

{
    _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 sind alle auf die Größe des Dokuments gezählt.

Ich habe noch nicht ein Problem mit der Grenze gesehen, die keine großen Dateien im Dokument selbst gespeichert beinhalteten. Es gibt bereits eine Vielzahl von Datenbanken, die sehr effizient sind bei Speichern / Abrufen von großen Dateien; sie sind Betriebssysteme genannt. Die Datenbank existiert als eine Schicht über das Betriebssystem. Wenn Sie eine NoSQL-Lösung aus Leistungsgründen verwenden, warum wollen Sie, indem Sie die DB-Schicht zwischen der Anwendung und Ihren Daten auf den Zugriff auf Ihren Daten zusätzlichen Verarbeitungsaufwand hinzufügen?

JSON ist ein Textformat. Also, wenn Sie Ihre Daten über JSON zugreifen, dies gilt insbesondere, wenn Sie binäre Dateien haben, weil sie in UUENCODE codiert werden müssen, hexadezimal oder Basis 64. Der Umsetzungsweg wie

aussehen könnte

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

Es wäre effizienter sein, den Weg zu bringen (URL) auf die Datendatei in Ihrem Dokument und halten Sie die Daten selbst in binär.

Wenn Sie wirklich diese Dateien unbekannter Länge in Ihrer DB behalten wollen, dann würden Sie wahrscheinlich besser dran, diese in GridFS setzen und nicht zu riskieren Ihre Gleichzeitigkeit zu töten, wenn die großen Dateien zugegriffen werden kann.

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

Mehr weitere Infos Vist

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

Sie sollten wahrscheinlich speichern Kommentare in einem separaten Sammel Beiträge sowieso bloggen.

[Bearbeiten]

Siehe Anmerkungen unten für die weitere Diskussion.

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

Wenn Sie erwarten, dass ein Blog-Post kann die 16Mb Dokument Grenze überschreiten, sollten Sie die Kommentare in eine separate Sammlung extrahieren und den Blog-Eintrag aus dem Kommentar verweisen und tun eine Anwendungsebene verbinden. 

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

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top