Suggerimenti per la pianificazione dello schema MongoDB

Una delle caratteristiche più pubblicizzate di MongoDB è la sua capacità di essere "senza schemi". Ciò significa che MongoDB non impone alcuno schema su alcun documento archiviato all'interno di una raccolta. Normalmente, MongoDB archivia i documenti in un formato JSON in modo che ogni documento possa memorizzare vari tipi di schema/struttura. Ciò è vantaggioso per le fasi iniziali dello sviluppo, ma nelle fasi successive potresti voler imporre la convalida dello schema mentre inserisci nuovi documenti per prestazioni e scalabilità migliori. In breve, "Schemaless" non significa che non devi progettare il tuo schema. In questo articolo, discuterò alcuni suggerimenti generali per la pianificazione del tuo schema MongoDB.

Capire il miglior design dello schema adatto alla tua applicazione può diventare noioso a volte. Ecco alcuni punti che puoi considerare durante la progettazione del tuo schema.

Evita documenti in crescita

Se il tuo schema consente la creazione di documenti che aumentano continuamente di dimensioni, dovresti adottare misure per evitarlo perché può portare a un degrado delle prestazioni di DB e I/O del disco. Per impostazione predefinita, MongoDB consente una dimensione di 16 MB per documento. Se la dimensione del documento aumenta di oltre 16 MB in un periodo di tempo, è un segno di una cattiva progettazione dello schema. A volte può portare al fallimento delle query. È possibile utilizzare i bucket di documenti o le tecniche di pre-allocazione dei documenti per evitare questa situazione. Nel caso in cui la tua applicazione debba archiviare documenti di dimensioni superiori a 16 MB, puoi prendere in considerazione l'utilizzo dell'API GridFS di MongoDB.

Evita di aggiornare interi documenti

Se provi ad aggiornare l'intero documento, MongoDB riscriverà l'intero documento altrove nella memoria. Ciò può ridurre drasticamente le prestazioni di scrittura del database. Invece di aggiornare l'intero documento, puoi utilizzare i modificatori di campo per aggiornare solo campi specifici nei documenti. Ciò attiverà un aggiornamento sul posto in memoria, quindi prestazioni migliorate.

Cerca di evitare i join a livello di applicazione

Come tutti sappiamo, MongoDB non supporta i join a livello di server. Pertanto, dobbiamo ottenere tutti i dati dal DB e quindi eseguire il join a livello di applicazione. Se stai recuperando dati da più raccolte e unisci una grande quantità di dati, devi chiamare DB più volte per ottenere tutti i dati necessari. Ciò richiederà ovviamente più tempo poiché coinvolge la rete. Come soluzione per questo scenario, se l'applicazione fa molto affidamento sui join, la denormalizzazione dello schema ha più senso. Puoi utilizzare i documenti incorporati per ottenere tutti i dati richiesti in un'unica chiamata di query.

Utilizza l'indicizzazione corretta

Durante la ricerca o l'aggregazione, spesso si ordinano i dati. Anche se si richiede l'ordinamento nell'ultima fase di una pipeline, è comunque necessario un indice per coprire l'ordinamento. Se il campo dell'indice sull'ordinamento non è disponibile, MongoDB è obbligato a eseguire l'ordinamento senza un indice. Esiste un limite di memoria di 32 MB della dimensione totale di tutti i documenti coinvolti nell'operazione di ordinamento. Se MongoDB raggiunge quel limite, potrebbe produrre un errore o restituire un set vuoto.

Dopo aver discusso dell'aggiunta di indici, è anche importante non aggiungere indici non necessari. Ogni indice che aggiungi nel database, devi aggiornare tutti questi indici mentre aggiorni i documenti nella raccolta. Ciò può ridurre le prestazioni del database. Inoltre, ogni indice occuperà spazio e memoria, quindi il numero di indici può causare problemi di archiviazione.

Un altro modo per ottimizzare l'uso di un indice è sovrascrivere il campo _id predefinito. L'unico scopo di questo campo è mantenere un campo univoco per documento. Se i tuoi dati contengono un timestamp o qualsiasi campo id, puoi sovrascrivere il campo _id e salvare un indice aggiuntivo.

Leggi il rapporto di scrittura v/s

La progettazione dello schema per qualsiasi applicazione dipende molto dal fatto che un'applicazione sia in lettura o in scrittura pesante. Ad esempio, se stai creando un dashboard per visualizzare i dati delle serie temporali, dovresti progettare lo schema in modo tale da massimizzare la velocità effettiva di scrittura. Se la tua applicazione è basata sull'e-commerce, la maggior parte delle operazioni saranno operazioni di lettura poiché la maggior parte degli utenti esaminerà tutti i prodotti e sfoglia i vari cataloghi. In questi casi, dovresti utilizzare lo schema denormalizzato per ridurre il numero di chiamate al database per ottenere dati rilevanti.

Tipi di dati BSON

Assicurati di definire correttamente i tipi di dati BSON per tutti i campi durante la progettazione dello schema. Perché quando modifichi il tipo di dati di qualsiasi campo, MongoDB riscriverà l'intero documento in un nuovo spazio di memoria. Ad esempio, se si tenta di memorizzare (int)0 al posto del campo (float)0.0, MongoDB riscrive l'intero documento a un nuovo indirizzo a causa della modifica del tipo di dati BSON.

Conclusione

In poche parole, è saggio progettare lo schema per il tuo database Mongo in quanto migliorerà solo le prestazioni della tua applicazione. A partire dalla versione 3.2, MongoDB ha iniziato a supportare la convalida dei documenti in cui è possibile definire quali campi sono necessari per inserire un nuovo documento. Dalla versione 3.6, MongoDB ha introdotto un modo più elegante per applicare la convalida dello schema utilizzando la convalida dello schema JSON. Utilizzando questo metodo di convalida, puoi imporre il controllo del tipo di dati insieme al controllo dei campi obbligatori. Puoi utilizzare gli approcci precedenti per verificare se tutti i documenti utilizzano lo stesso tipo di schema o meno.