limite di dimensione MongoDB BSON documento Understanding

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

  •  10-10-2019
  •  | 
  •  

Domanda

Da MongoDB The Definitive Guide:

  

I documenti più grandi di 4 MB (quando convertito in BSON) non può essere   salvati nel database. Questo è un limite alquanto arbitraria (e può essere   sollevato in futuro); è per lo più per prevenire progettazione dello schema cattivo e garantire   prestazioni costanti.

Non capisco questo limite, fa questo

media 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?

Anche fa questo conteggio i documenti nidificati troppo?

E se io volessi un documento che rivede le modifiche a un valore. (E alla fine possa crescere, superamento del limite 4MB.)

La speranza che qualcuno lo spiega in modo corretto.

Ho appena iniziato a leggere su MongoDB (primo database NoSQL sto imparando circa).

Grazie.

È stato utile?

Soluzione

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:

Modifica Il formato è stato ufficialmente a 16MB

  

Quindi, il tuo esempio blog, 4MB è   in realtà un bel po '.. Per esempio,   il testo decomprime pieni 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   andare a leggerlo:)

     

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

     

Quindi, ad eccezione di veramente bizzarro   situazioni, sarà grande lavoro. e in   il caso un'eccezione o spam, davvero   non credo che ci si vuole un oggetto 20mb   Comunque. Penso tappatura riferimenti come   15k o così fa un sacco di senso no   importa che per le prestazioni. O a   involucro almeno speciale se mai   accade.

     

-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 MBs del documento nella RAM quando si esegue una query di esso.)

Quindi, il limite è una certa% del normale RAM utilizzabile su un sistema comune ... che manterrà anno cresce in anno.

Nota sulla memorizzazione dei file in MongoDB

Se avete bisogno di archiviare 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 a voi (evitando così 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 negozi di ogni blocco in un documento separato.

     

GridFS utilizza due collezioni di file di archivio. negozi Una raccolta i pezzi di file, e l'altra di metadati negozi di file.

È possibile utilizzare questo metodo per memorizzare immagini, file, video, ecc nel database quanto si potrebbe in un database SQL. Ho usato questo per memorizzare anche a più file video Gigabyte.

Altri suggerimenti

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 una "caratteristica" importante nella fase iniziale. Non stanno andando a cambiare in qualunque momento presto perché i loro sentimenti sono feriti che chiunque ha messo in dubbio. Un altro esempio della personalità e della politica nulla togliere un prodotto nelle comunità open source, ma questo non è davvero un problema paralizzante.

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

Il formato del documento include tutto nel documento inclusi i documenti secondari, 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.

Sbudocuments e oggetti nidificati sono tutti contati verso le dimensioni del documento.

Non ho ancora visto un problema con il limite che non ha comportato grandi file memorizzati all'interno del documento stesso. Ci sono già una serie di banche dati che sono molto efficienti a memorizzazione / recupero di file di grandi dimensioni; essi sono chiamati sistemi operativi. Il database esiste come strato sopra il sistema operativo. Se si utilizza una soluzione NoSQL per motivi di prestazioni, perché si vuole aggiungere un ulteriore sovraccarico di elaborazione per l'accesso dei dati mettendo il livello DB tra l'applicazione ei dati?

JSON è un formato di testo. Quindi, se si accede i dati attraverso JSON, questo è particolarmente vero se si dispone di file binari perché devono essere codificati in uuencode, esadecimale, o base 64. Il percorso di conversione potrebbe apparire come

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

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

Se si vuole veramente conservare questi file di lunghezza sconosciuta nel vostro DB, allora si sarebbe probabilmente meglio mettere questi in GridFS e non rischiare di uccidere la vostra concorrenza quando i file di grandi dimensioni sono accessibili.

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

Più informazioni vist

Forse la memorizzazione di un post sul blog -.> Commenti rapporto in un database non relazionale non è davvero il miglior design

Si dovrebbe probabilmente memorizzare commenti in una raccolta differenziata al post del blog in ogni caso.

[modifica]

vedi commenti qui sotto per ulteriori discussioni.

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

Se ci si aspetta che un post sul blog può superare il limite del documento 16Mb, si dovrebbe estrarre i commenti in una raccolta differenziata e fare riferimento al post sul blog dal commento e fare uno a livello di applicazione unirsi. 

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

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top