Comprensione del limite della dimensione del documento MongoDB BSON

Da MongoDB La guida definitiva:

I documenti di dimensioni superiori a 4 MB (quando convertiti in BSON) non possono essere salvati nel database. Questo è un limite un po 'arbitrario (e potrebbe essere aumentato in futuro); è principalmente per prevenire la cattiva progettazione dello schema e garantire prestazioni costanti.

Non capisco questo limite, questo significa che un documento contenente un post sul blog con molti commenti che in questo caso supera i 4 MB non può essere archiviato come un singolo documento?

Anche questo conta anche i documenti nidificati?

E se volessi un documento che controlla le modifiche a un valore. (Alla fine potrebbe crescere, superando il limite di 4 MB.)

Spero che qualcuno lo spieghi correttamente.

Ho appena iniziato a leggere su MongoDB (primo database nosql di cui sto imparando).

Grazie.

Prima di tutto, questo in realtà viene sollevato nella prossima versione di 8MBo 16MB... ma penso di metterlo in prospettiva, Eliot di 10gen (che ha sviluppato MongoDB) lo mette meglio:

EDIT: la dimensione è stata ufficialmente "aumentata" a16MB

Quindi, nell'esempio del tuo blog, 4 MB sono in realtà un sacco ... Ad esempio, il testo completo non compresso di "War of the Worlds" è solo 364k (html): http://www.gutenberg.org/etext/36

Se il tuo post sul blog è così lungo con così tanti commenti, io per primo non lo leggerò :)

Per i trackback, se hai dedicato 1 MB a loro, potresti facilmente avere più di 10k (probabilmente più vicino a 20k)

Quindi, tranne per le situazioni davvero bizzarre, funzionerà alla grande. E nel caso dell'eccezione o dello spam, non credo davvero che vorresti comunque un oggetto da 20 MB. Penso che limitare i trackback come 15k o giù di lì abbia molto senso, non importa quale sia per le prestazioni. O almeno involucro speciale se mai dovesse succedere.

-Eliot

Penso che saresti abbastanza difficile raggiungere il limite ... e col tempo, se aggiorni ... dovrai preoccuparti sempre meno.

Il punto principale del limite è quindi di non utilizzare tutta la RAM sul server (poiché è necessario caricare tutti i messaggi MBs nella RAM durante la query).

Quindi il limite è un po 'della normale RAM utilizzabile su un sistema comune ... che continuerà a crescere anno dopo anno.

Nota sulla memorizzazione di file in MongoDB

Se è necessario archiviare documenti (o file) di dimensioni superiori 16MBa quelle disponibili, è possibile utilizzare l' API GridFS che suddividerà automaticamente i dati in segmenti e li trasmetterà di nuovo a voi (evitando così il problema con limiti di dimensioni / RAM).

Invece di archiviare un file in un singolo documento, GridFS divide il file in parti o blocchi e memorizza ogni blocco come documento separato.

GridFS utilizza due raccolte per archiviare i file. Una raccolta memorizza i blocchi di file e l'altra memorizza i metadati dei file.

È possibile utilizzare questo metodo per archiviare immagini, file, video, ecc. Nel database, proprio come si farebbe in un database SQL. L'ho usato anche per archiviare file video multi gigabyte.

Molti nella comunità preferirebbero nessun limite con avvertimenti sulle prestazioni, vedi questo commento per un argomento ben ragionato: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin. system.issuetabpanels: commento-tabpanel # comment-22283

La mia opinione è che gli sviluppatori principali sono testardi su questo problema perché hanno deciso che era una "caratteristica" importante all'inizio. Non lo cambieranno presto perché i loro sentimenti sono feriti e qualcuno l'ha messo in discussione. Un altro esempio di personalità e politica che toglie un prodotto nelle comunità open source ma questo non è davvero un problema paralizzante.

Per pubblicare una risposta di chiarimento qui per coloro che vengono indirizzati qui da Google.

Le dimensioni del documento includono tutto il documento inclusi i documenti secondari, gli oggetti nidificati ecc.

Quindi un documento di:

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

Ha una dimensione massima di 16meg.

Sbudocumenti e oggetti nidificati vengono tutti conteggiati in base alle dimensioni del documento.

Non ho ancora visto un problema con il limite che non comportava file di grandi dimensioni memorizzati nel documento stesso. Esistono già una varietà di database molto efficienti nell'archiviazione / recupero di file di grandi dimensioni; sono chiamati sistemi operativi. Il database esiste come layer sul sistema operativo. Se si utilizza una soluzione NoSQL per motivi di prestazioni, perché aggiungere un ulteriore sovraccarico di elaborazione all'accesso dei dati inserendo il livello DB tra l'applicazione e i dati?

JSON è un formato di testo. Quindi, se stai accedendo ai tuoi dati tramite JSON, questo è particolarmente vero se hai file binari perché devono essere codificati in uuencode, esadecimale o Base 64. Il percorso di conversione potrebbe apparire come

file binario <> JSON (codificato) <> BSON (codificato)

Sarebbe più efficiente inserire il percorso (URL) nel file di dati nel documento e mantenere i dati stessi in binario.

Se vuoi davvero mantenere questi file di lunghezza sconosciuta nel tuo DB, probabilmente sarebbe meglio metterli in GridFS e non rischiare di uccidere la tua concorrenza quando si accede a file di grandi dimensioni.

Profondità nidificata per documenti BSON: MongoDB supporta non più di 100 livelli di annidamento per documenti BSON.

Ulteriori informazioni

Forse memorizzare un post sul blog -> relazione di commenti in un database non relazionale non è proprio il miglior design.

Probabilmente dovresti comunque archiviare i commenti in una raccolta separata per pubblicare post sul blog.

[modificare]

Vedi i commenti qui sotto per ulteriori discussioni.

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

Se ti aspetti che un post sul blog possa superare il limite del documento di 16 Mb, devi estrarre i commenti in una raccolta separata e fare riferimento al post del blog dal commento ed eseguire un join a livello di applicazione.

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

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