MongoDB BSON limite di dimensione dei documenti intesa

Question

Da MongoDB The Definitive Guide:

documenti più grandi di 4MB (se convertito in BSON) non possono essere salvati nel database. Questo è un limite un po 'arbitrario (e potrebbe essere generato in futuro); serve principalmente a prevenire la progettazione di uno schema errato e garantisce prestazioni uniformi .

non capisco questo limite, questo significa che un documento contenente un post sul blog con un sacco di commenti, che così succede di essere più grande di 4MB non può essere memorizzato come un unico documento?

Questo conta anche i documenti nidificati?

E se volessi un documento che controlli le modifiche ad 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 (il primo database nosql che sto imparando).

Grazie.

Answer 1

Prima di tutto, questo in realtà è cresciuto nella prossima versione di 8MB o 16MB ... ma penso che a mettere questo in prospettiva, Eliot da 10gen (che ha sviluppato MongoDB) lo mette meglio:

EDIT :la dimensione è stata officially 'sollevato' per 16MB

Così, il vostro esempio blog, 4MB è in realtà un bel po '.. per esempio, l'u completo testo ncompresses di "La guerra dei mondi" è solo 364k (html): http://www.gutenberg.org/etext/36

Se il tuo post sul blog è che a lungo con che molti commenti, io per primo non sono intenzione di leggerlo :)

per i riferimenti, se dedicato 1MB a loro, si potrebbe facilmente avere più di 10k (probabilmente più vicino a 20k)

Dunque, salvo veramente bizzarre situazioni, sarà grande lavoro. E in il caso di eccezione o lo spam, io davvero non penso che tu voglia un oggetto 20mb comunque.Penso che limitare i trackback come 15k o così non abbia molto senso che lo sia importante per le prestazioni. O al involucro meno speciale se mai si verifica .

-Eliot

penso che sarebbe pigiato piuttosto difficile da raggiungere il limite ... e nel corso del tempo, se si aggiorna ... ti devi preoccupare meno.

Il punto principale del limite è così non si utilizza tutta la RAM sul vostro server (come è necessario per caricare tutti MB s del documento nella RAM quando si esegue una query di esso.)

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

Nota sulla memorizzazione dei file in MongoDB

Se avete bisogno di memorizzare i documenti (o file) più grandi di 16MB è possibile utilizzare il GridFS API che romperà automaticamente il backup dei dati in segmenti e li lo streaming di nuovo voi (evitando il problema con limiti di dimensione/RAM.)

Invece di memorizzare un file in un unico documento, GridFS divide il file in parti o pezzi, e memorizza ogni blocco da un documento separato.

GridFS utilizza due raccolte per memorizzare i file. Una raccolta memorizza i blocchi di file e gli altri archivi memorizzano i metadati.

È possibile utilizzare questo metodo per memorizzare immagini, file, video, ecc. Nel database come si potrebbe in un database SQL. Ho usato questo anche per archiviare file video multi gigabyte.

Answer 2

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

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

[modifica]

Vedi commenti qui sotto per ulteriori discussioni.

Answer 3

Molti nella comunità preferirebbe senza limiti con avvertimenti circa le prestazioni, vedere questo commento per un argomento ben ragionata: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-22283

Il mio introito, gli sviluppatori di piombo sono testardi su questo problema perché hanno deciso che era un importante "funzionalità" presto. Non lo cambieranno in qualsiasi momento presto perché i loro sentimenti sono feriti che qualcuno l'ha interrogato. Un altro esempio di personalità e politica che distacca da un prodotto nelle comunità open source, ma questo non è davvero un problema paralizzante.

Answer 4

Non ho ancora riscontrato un problema con il limite che non riguardava file di grandi dimensioni memorizzati all'interno del documento stesso. Esistono già numerosi database che sono molto efficienti nella memorizzazione/nel recupero di file di grandi dimensioni; sono chiamati sistemi operativi. Il database esiste come livello sul sistema operativo. Se si sta utilizzando una soluzione NoSQL per motivi di prestazioni, perché si desidera aggiungere ulteriore overhead di elaborazione all'accesso dei dati inserendo il livello DB tra l'applicazione ei dati?

JSON è un formato di testo. Pertanto, se si accede ai dati tramite JSON, ciò è particolarmente vero se si dispone di file binari perché devono essere codificati in uuencode, esadecimale o Base 64.Il percorso di conversione potrebbe essere simile

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

Sarebbe più efficace per mettere il percorso (URL) per il file di dati nel documento e mantenere la dati stessi in binario.

Se si desidera mantenere questi file di lunghezza sconosciuta nel DB, sarebbe probabilmente meglio inserirli in GridFS e non rischiare di uccidere la concorrenza quando si accede ai file di grandi dimensioni.

Answer 5

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

le dimensioni del documento include tutto nel documento inclusi i documenti secondari, oggetti nidificati ecc

Così 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.

Gli strumenti secondari e gli oggetti nidificati vengono contati per le dimensioni del documento.

Answer 6

profondità nidificati per BSON Documenti: MongoDB supporta non più di 100 livelli di nidificazione per i documenti BSON.

More more info vist