MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Novità di MongoDB 4.2

Gli aggiornamenti del database includono funzionalità migliorate per prestazioni, sicurezza e nuove funzionalità integrate. È sempre consigliabile testare una nuova versione prima di implementarla in produzione, solo per assicurarsi che soddisfi le proprie esigenze e non vi siano possibilità di arresti anomali.

Considerando molti prodotti, quelli che precedono le prime versioni secondarie di una nuova versione principale hanno le correzioni più importanti. Ad esempio, preferirei avere MongoDB versione 4.2.1 in produzione pochi giorni dopo il rilascio rispetto alla versione 4.2.0.

In questo blog discuteremo cosa è stato incluso e quali miglioramenti sono stati apportati a MongoDB versione 4.2

Novità di MongoDB 4.2

  1. Transazioni distribuite
  2. Indici jolly
  3. Letture e scritture riprovabili
  4. Crittografia automatica a livello di campo lato client.
  5. Linguaggio di query migliorato per aggiornamenti espressivi
  6. Viste materializzate su richiesta
  7. Operazioni di manutenzione moderna

Transazioni distribuite

Le transazioni sono importanti funzionalità del database che garantiscono la coerenza e l'integrità dei dati, in particolare quelle che garantiscono le procedure ACID. MongoDB versione 4.2 ora supporta transazioni multi-documento su set di repliche e un cluster partizionato attraverso l'approccio della transazione distribuita. È stata mantenuta la stessa sintassi per l'utilizzo delle transazioni della precedente versione 4.0.

Tuttavia, le specifiche del driver del client sono leggermente cambiate, quindi se si intende utilizzare le transazioni in MongoDB 4.2, è necessario aggiornare i driver a versioni compatibili con i server 4.2.

Questa versione non limita le dimensioni di una transazione in termini di utilizzo della memoria, ma dipende solo dalle dimensioni dell'hardware e dalla capacità di gestione dell'hardware.

La riassegnazione globale delle impostazioni locali del cluster è ora possibile con la versione 4.2. Vale a dire, per un'implementazione del partizionamento orizzontale della zona geografica, se un utente residente nella regione A si sposta nella regione B, modificando il valore del campo relativo alla posizione, i dati possono essere spostati automaticamente dalla regione A alla B tramite una transazione.

Il sistema di sharding ora consente di modificare una chiave shard contrariamente alla versione precedente. Letteralmente, quando una chiave shard viene modificata, equivale a spostare il documento su un altro shard. In questa versione, MongoDB esegue il wrapping di questo aggiornamento e se il documento deve essere spostato da uno shard all'altro, l'aggiornamento verrà eseguito all'interno di una transazione in background.

L'uso delle transazioni non è un approccio consigliabile poiché degradano le prestazioni del database soprattutto se si verificano più volte. Durante un periodo di transazione, c'è una finestra estesa per le operazioni che possono causare conflitti quando si effettuano scritture su un documento interessato. Per quanto una transazione possa essere ritentata, potrebbe esserci un aggiornamento apportato al documento prima di questo nuovo tentativo e ogni volta che si verifica il nuovo tentativo, potrebbe gestire la versione del documento precedente anziché quella più recente. I tentativi ovviamente comportano costi di elaborazione maggiori oltre ad aumentare i tempi di inattività dell'applicazione a causa della crescente latenza.

Una buona pratica sull'utilizzo delle transazioni include:

  1. Evita di utilizzare query non indicizzate all'interno di una transazione per garantire che l'operazione non sia lenta.
  2. La tua transazione dovrebbe comprendere alcuni documenti.

Con il formato dello schema dinamico MongoDB e la funzione di incorporamento, puoi scegliere di inserire tutti i campi nella stessa raccolta per evitare la necessità di utilizzare la transazione come prima misura.

Indici jolly

Gli indici jolly sono stati introdotti in MongoDB versione 4.2 per migliorare le query su campi arbitrari o i cui nomi non sono noti in anticipo, indicizzando l'intero documento o sottodocumento. Non intendono sostituire gli indici basati sul carico di lavoro ma si adatta al lavoro con dati che coinvolgono pattern polimorfici. Un modello polimorfico è dove tutti i documenti in una raccolta sono simili ma non hanno una struttura identica. I modelli di dati polimorfici possono essere generati da applicazioni che coinvolgono, cataloghi di prodotti o dati sociali. Di seguito è riportato un esempio di dati di raccolta polimorfici

{

Sport: ‘Chess’,

playerName: ‘John Mah’,

Career_earning: {amount: NumberDecimal(“3000”), currency: “EUR”},

gamesPlayed:25,

career_titles:10

},

{

Sport: Tennis,

playerName: ‘Semenya Jones,

Career_earning: {amount: NumberDecimal(“34545”), currency: “USD”},

Event: {

name:”Olympics”,

career_titles:10,

career_tournaments:14

}

Indicizzando l'intero documento utilizzando gli indici con caratteri jolly, puoi eseguire una query utilizzando qualsiasi campo arbitrario come indice.

Per creare un indice di caratteri jolly

$db.collection.createIndex({“fieldA.$**”: 1})

Se il campo selezionato è un documento nidificato o un array, l'indice dei caratteri jolly ricorre nel documento e memorizza il valore per tutti i campi nel documento o nell'array.

Letture e scritture riprovabili

Normalmente un database può subire frequenti interruzioni transitorie della rete che possono comportare l'annullamento parziale o totale di una query. Questi errori di rete potrebbero non essere così gravi, quindi offrono la possibilità di riprovare queste query una volta ricollegate. A partire da MongoDB 4.2, la configurazione dei tentativi è abilitata per impostazione predefinita. I driver MongoDB possono ritentare letture e scritture non riuscite per determinate transazioni ogni volta che riscontrano errori di rete minori o piuttosto quando non sono in grado di trovare un primario integro nel set di repliche / cluster partizionato. Tuttavia, se non vuoi le scritture riprovabili, puoi disabilitarle esplicitamente nelle tue configurazioni ma non trovo un motivo convincente per cui uno dovrebbe disabilitarle.

Questa funzione serve a garantire che in ogni caso, in caso di modifiche all'infrastruttura MongoDB, il codice dell'applicazione non dovrebbe essere influenzato. Riguardo a un esempio spiegato da Eliot Horowitz, il co-fondatore di MongoDB, per una pagina web che esegue 20 diverse operazioni di database, invece di ricaricare l'intera cosa o dover avvolgere l'intera pagina web in una sorta di loop, il driver sotto le coperte può semplicemente decidere di riprovare l'operazione. Ogni volta che una scrittura fallisce, ritenterà automaticamente e avrà un contratto con il server per garantire che ogni scrittura avvenga solo una volta.

Le scritture retryable effettuano solo un singolo tentativo di nuovo che aiuta a risolvere le elezioni del set di repliche e gli errori di rete transitori, ma non per gli errori di rete persistenti.

Le scritture retryable non affrontano le istanze in cui il periodo di failover supera il valore serverSelectionTimoutMs nelle configurazioni dei parametri.

Con questa versione di MongoDB, è possibile aggiornare i valori della chiave shard del documento (tranne se lo shardkey è il campo _id immutabile) emettendo un'operazione findAndModify/update di un singolo documento in una transazione o come scrittura ritentiva .

MongoDB versione 4.2 ora può riprovare un'operazione di upsert di un singolo documento (cioè upsert:true e multi:false) che potrebbe non essere riuscita a causa di un errore di chiave duplicata se l'operazione soddisfa queste condizioni chiave:

  1. La raccolta di destinazione contiene un indice univoco che ha generato un errore di chiave duplicata.
  2. L'operazione di aggiornamento non modificherà nessuno dei campi nel predicato della query.
  3. La condizione di corrispondenza di aggiornamento è un singolo predicato di uguaglianza {field:"value"} o un AND logico di predicati di uguaglianza {filed:"value", field0:"value0"}
  4. L'insieme di campi nel modello di chiave dell'indice univoco corrisponde all'insieme di campi nel predicato della query di aggiornamento.

Crittografia automatica a livello di campo lato client

MongoDB versione 4.2 include la crittografia automatica a livello di campo lato client (CSFLE), una funzionalità che consente agli sviluppatori di crittografare selettivamente i singoli campi di un documento sul lato client prima che venga inviato al server. I dati crittografati vengono quindi mantenuti privati ​​dai provider che ospitano il database e da qualsiasi utente che potrebbe avere accesso diretto al database.

Solo le applicazioni con l'accesso alle chiavi di crittografia corrette possono decrittare e leggere i dati protetti. Nel caso in cui la chiave di crittografia venga eliminata, tutti i dati crittografati verranno resi illeggibili.

Nota:questa funzione è disponibile solo con MongoDB enterprise.

Linguaggio di query migliorato per aggiornamenti espressivi

MongoDB versione 4.2 fornisce un linguaggio di query più ricco rispetto ai suoi predecessori. Ora supporta le aggregazioni e le moderne operazioni sui casi d'uso sulla falsariga di ricerche basate su geolocalizzazione, ricerca di grafici e ricerca di testo. Ha integrato un motore di ricerca di terze parti che rende le ricerche più veloci considerando che il motore di ricerca è in esecuzione su un processo/server diverso. Questo generalmente migliora le prestazioni del database contrariamente a se tutte le ricerche fossero eseguite nel processo mongod che preferirebbe rendere volatile la latenza delle operazioni del database ogni volta che il motore di ricerca reindicizza.

Con questa versione, ora puoi gestire array, fare somme e altre operazioni matematiche direttamente tramite un'istruzione di aggiornamento.

Viste materializzate su richiesta

Il framework della pipeline di aggregazione dei dati in MongoDB è un'ottima funzionalità con diverse fasi di trasformazione di un documento nello stato desiderato. La versione 4.2 di MongoDB introduce una nuova fase $merge che per me dirò che mi ha fatto risparmiare un po' di tempo lavorando con l'output finale che doveva essere archiviato in una raccolta. Inizialmente, la fase $out permette di creare una nuova collezione basata sull'aggregazione e popola la collezione con i risultati ottenuti. Se la raccolta esiste già, sovrascriverebbe la raccolta con i nuovi risultati contrariamente alla fase $merge che incorpora solo i risultati della pipeline in un output esistente anziché sostituire completamente la raccolta. La rigenerazione di un'intera raccolta ogni volta con la fase $out consuma molta CPU e I/O che possono degradare le prestazioni del database. Il contenuto dell'output sarà quindi aggiornato tempestivamente consentendo agli utenti di creare viste materializzate su richiesta

Operazioni di manutenzione moderna

Gli sviluppatori possono ora avere un'esperienza operativa eccezionale con MongoDB versione 4.2 con funzionalità integrate che migliorano l'elevata disponibilità, la strategia di backup gestita dal cloud, migliorano la potenza di monitoraggio e i sistemi di avviso. MongoDB Atlas e MongoDB Ops Manager sono le piattaforme che forniscono queste funzionalità. Quest'ultimo è stato etichettato come il migliore per l'esecuzione di MongoDB in azienda. È stato inoltre integrato con l'operatore Kubernetes per gli utenti locali che passano al cloud privato. Questa interfaccia consente di controllare direttamente Ops Manager.

Ci sono alcune modifiche interne apportate a MongoDB versione 4.2 che includono:

  1. Elenco dei cursori aperti.
  2. Rimozione del motore di archiviazione MMAPv1.
  3. Miglioramento sulla riparazione del file di dati WiredTiger.
  4. I campi diagnostici ora possono avere queryHash
  5. Il thread di divisione automatica per i nodi mongos è stato rimosso.

Conclusione

MongoDB versione 4.2 include alcuni miglioramenti in termini di sicurezza e prestazioni del database. Ha incluso una crittografia automatica a livello di campo lato client che garantisce che i dati siano protetti dal punto di vista del client. Più funzionalità come un motore di ricerca di terze parti e l'inclusione della fase $merge nel framework di aggregazione migliorano le prestazioni del database. Prima di mettere in produzione questa versione, assicurati che tutte le tue esigenze siano completamente soddisfatte.