Ottimizzare le prestazioni di scrittura in Azure Cosmos DB per MongoDB

  • Articolo

SI APPLICA A: MongoDB

L'ottimizzazione delle prestazioni di scrittura consente di sfruttare al meglio la scalabilità illimitata di Azure Cosmos DB for MongoDB. A differenza di altri servizi MongoDB gestiti, l'API per MongoDB esegue automaticamente e in modo trasparente il partizionamento orizzontale delle raccolte (quando si usano raccolte partizionate) per ridimensionarsi in modo illimitato.

La modalità di scrittura dei dati deve tenere presente questo aspetto parallelizzando e distribuendo i dati tra le partizioni per ottenere il maggior numero possibile di scritture dai database e dalle raccolte. Questo articolo illustra le procedure consigliate per ottimizzare le prestazioni di scrittura.

Distribuire il carico tra le partizioni

Quando si scrivono dati in una raccolta partizionata dell'API per MongoDB, i dati vengono suddivisi (partizionati) in sezioni minuscole e quindi scritti in ogni partizione in base al valore del campo della chiave di partizione. È possibile considerare ogni sezione come una piccola parte di una macchina virtuale che archivia solo i documenti contenenti un valore univoco della chiave di partizione.

Se l'applicazione scrive una grande quantità di dati in una singola partizione, questa operazione non sarà efficiente perché l'app sfrutterà al massimo la velocità effettiva di una sola partizione invece di distribuire il carico tra tutte le partizioni. Per distribuire uniformemente il carico della scrittura nella raccolta, sarà necessario scrivere in parallelo in molti documenti con valori di chiave di partizione univoci.

Un esempio di questa operazione è offerto da un'applicazione di catalogo prodotti partizionata in base al campo della categoria. Anziché scrivere in una sola categoria (partizione) alla volta, è preferibile scrivere in tutte le categorie contemporaneamente per ottenere la massima velocità effettiva di scrittura.

Ridurre il numero di indici

L'indicizzazione è un'ottima funzionalità per ridurre drasticamente il tempo necessario per eseguire query sui dati. Per la massima flessibilità nell'esperienza di query, l'API per MongoDB abilita per impostazione predefinita un indice con caratteri jolly sui dati per eseguire query su tutti i campi in modo rapido. Tuttavia, tutti gli indici, inclusi quelli con caratteri jolly, introducono un carico aggiuntivo durante la scrittura dei dati perché le operazioni di scrittura modificano la raccolta e gli indici.

Limitando il numero di indici a quelli necessari per supportare le query, le operazioni di scrittura saranno più veloci ed economiche. Come regola generale, è consigliabile adottare i criteri seguenti:

  • Qualsiasi campo usato per filtrare i dati deve avere un indice a campo singolo corrispondente. Questa opzione consente anche di filtrare in base a più campi.
  • Qualsiasi gruppo di campi in base a cui si esegue l'ordinamento deve avere uno specifico indice composito.

Impostare l'opzione "ordered" su "false" nei driver MongoDB

Per impostazione predefinita, i driver MongoDB impostano l'opzione "ordered" su "true" durante la scrittura dei dati, scrivendo così ogni documento uno dopo l'altro. Questa opzione riduce le prestazioni di scrittura perché ogni richiesta di scrittura deve attendere il completamento del precedente. Quando si scrivono dati, impostare questa opzione su "false" per migliorare le prestazioni.

db.collection.insertMany(
   [ <doc1> , <doc2>, ... ],
   {
      ordered: false
   }
)

Ottimizzare le dimensioni dei batch e il numero di thread

La parallelizzazione in molti thread/processi è fondamentale per ridimensionare le operazioni di scrittura. L'API per MongoDB accetta scritture in batch di un massimo di 1000 documenti per singolo processo/thread.

Se si scrivono più di 1000 documenti alla volta per processo/thread, le funzioni client come insertMany() devono essere limitate a circa 1000 documenti. In caso contrario, il client attenderà il commit di ogni batch prima di passare al batch successivo. In alcuni casi, la suddivisione dei batch con meno o leggermente più di 1000 documenti sarà più veloce.

Passaggi successivi