Le migliori pratiche per Amazon DocumentDB

Scopri le best practice per lavorare con Amazon DocumentDB (con compatibilità MongoDB). Questa sezione viene continuamente aggiornata man mano che vengono identificate nuove best practice.

Linee guida operative di base

Le seguenti sono linee guida operative di base che tutti dovrebbero seguire quando lavorano con Amazon DocumentDB. L'accordo sul livello di servizio di Amazon DocumentDB richiede il rispetto di queste linee guida.

• Distribuisci un cluster composto da due o più istanze Amazon DocumentDB in due zone di disponibilità. AWS Per i carichi di lavoro di produzione, distribuisci un cluster composto da tre o più istanze Amazon DocumentDB in tre zone di disponibilità.

• Utilizza il servizio nei limiti indicati. Per ulteriori informazioni, consulta Quote Amazon DocumentDB.

• Monitora l'utilizzo della memoria, della CPU, delle connessioni e dello storage. Per aiutarti a mantenere le prestazioni e la disponibilità del sistema, configura Amazon in CloudWatch modo da notificarti quando i modelli di utilizzo cambiano o quando ti avvicini alla capacità della tua distribuzione.

• Incrementa la capacità delle istanze quando stai per raggiungere i limiti della capacità di storage. È necessario eseguire il provisioning delle istanze con risorse di calcolo sufficienti (ad esempio, RAM, CPU) per soddisfare aumenti imprevisti della domanda da parte delle applicazioni.

• Imposta il periodo di retention dei backup per allineare l'obiettivo del punto di ripristino.

• Prova il failover per il cluster per capire quanto tempo impiega il processo per il tuo caso d'uso. Per ulteriori informazioni, consulta Failover di Amazon DocumentDB.

• Connettiti al tuo cluster Amazon DocumentDB con l'endpoint del cluster (vediEndpoint Amazon DocumentDB) e in modalità replica set (vediConnessione ad Amazon DocumentDB come set di repliche) per ridurre al minimo l'impatto di un failover sulla tua applicazione.

• Scegli un’impostazione di preferenza di lettura del driver che massimizza il dimensionamento della lettura nel rispetto dei requisiti di coerenza di lettura dell'applicazione. La preferenza di lettura secondaryPreferred consente la lettura delle repliche e libera l'istanza primaria per eseguire ulteriori operazioni. Per ulteriori informazioni, consulta Leggi le opzioni di preferenza.

• Progetta la tua applicazione per essere resiliente in caso di errori della rete e del database. Usa il meccanismo di errore del driver per distinguere tra errori temporanei ed errori persistenti. Ripeti gli errori temporanei utilizzando un meccanismo di backoff esponenziale quando appropriato. Assicurati che l'applicazione consideri la coerenza dei dati quando implementa una logica di ripetizione.

• Attiva la protezione dell'eliminazione dei cluster per tutti i cluster di produzione o per qualsiasi cluster contenente dati importanti. Prima di eliminare un cluster Amazon DocumentDB, scatta un'istantanea finale. Se stai distribuendo risorse con CloudFormation, abilita la protezione dalla terminazione. Per ulteriori informazioni, consulta Protezione dalla terminazione e protezione dall'eliminazione.

• Quando si crea un cluster Amazon DocumentDB, --engine-version è un parametro opzionale il cui valore predefinito è l'ultima versione principale del motore. L'attuale versione predefinita del motore è 5.0.0 (nota: Amazon DocumentDB 8.0 è disponibile ma deve essere specificata esplicitamente). Quando vengono rilasciate nuove versioni principali del motore, la versione predefinita del motore --engine-version verrà aggiornata per riflettere l'ultima versione principale del motore. Di conseguenza, per i carichi di lavoro di produzione, e in particolare quelli che dipendono da script, automazione o CloudFormation modelli, specifica esplicitamente la versione --engine-version principale prevista.

Dimensionamento delle istanze

Uno degli aspetti più critici nella scelta della dimensione di un'istanza in Amazon DocumentDB è la quantità di RAM per la cache. Amazon DocumentDB riserva un terzo della RAM per i propri servizi, il che significa che solo due terzi della RAM dell'istanza sono disponibili per la cache. Pertanto, è una best practice di Amazon DocumentDB scegliere un tipo di istanza con RAM sufficiente per contenere in memoria il tuo set di lavoro (ad esempio dati e indici). Avere istanze di dimensioni adeguate aiuterà a ottimizzare le prestazioni complessive e potenzialmente a minimizzare i costi. I/O Puoi utilizzare il calcolatore di dimensionamento di Amazon DocumentDB di terze parti per stimare la dimensione dell'istanza per un particolare carico di lavoro.

Per determinare se il set di lavoro dell'applicazione è compatibile con la memoria, monitora l'BufferCacheHitRatioutilizzo di Amazon CloudWatch per ogni istanza in un cluster sottoposto a carico.

La BufferCacheHitRatio CloudWatch metrica misura la percentuale di dati e indici forniti dalla cache di memoria di un'istanza (rispetto al volume di archiviazione). In generale, il valore di BufferCacheHitRatio dovrebbe essere il più alto possibile, poiché la lettura dei dati dalla memoria del working set è più veloce e più conveniente rispetto alla lettura dal volume di archiviazione. Anche se è consigliabile mantenere il valore BufferCacheHitRatio il più vicino possibile al 100%, il miglior valore ottenibile dipenderà dai modelli di accesso e dai requisiti di prestazione dell'applicazione. Per mantenere il massimo valore BufferCacheHitRatio possibile , si consiglia di eseguire il provisioning delle istanze del cluster con una sufficiente quantità di RAM per poter adattare gli indici e i working set di dati in memoria.

Se i tuoi indici non si adattano alla memoria, vedrai un valore inferiore BufferCacheHitRatio. La lettura continua da disco comporta I/O costi aggiuntivi e non è migliore della lettura dalla memoria. Se il rapporto BufferCacheHitRatio è inferiore al previsto, aumentare la dimensione dell'istanza del cluster per fornire più RAM per adattare i dati del working set in memoria. Se il ridimensionamento della classe di istanza si traduce in un aumento drastico di BufferCacheHitRatio, il set di lavoro dell'applicazione non si adattava alla memoria. Continua con l'incremento fino a quando il valore di BufferCacheHitRatio non aumenta più drasticamente dopo un'operazione di dimensionamento. Per ulteriori informazioni sul monitoraggio dei parametri di un'istanza, consulta Metriche di Amazon DocumentDB.

A seconda del carico di lavoro e dei requisiti di latenza, potrebbe essere accettabile che l'applicazione abbia valori BufferCacheHitRatio più elevati durante l'utilizzo della fase costante, ma abbia periodicamente delle riduzioni dei valori BufferCacheHitRatio quando le query analitiche che devono eseguire la scansione di un'intera raccolta vengono eseguite su un'istanza. Questi riduzioni periodiche del valore BufferCacheHitRatio possono manifestarsi come latenza più elevata per le query successive che devono ripopolare i dati del working set dal volume di archiviazione nella cache del buffer. Testa i tuoi carichi di lavoro in un ambiente di pre-produzione con un carico di lavoro di produzione rappresentativo innanzitutto per comprendere le caratteristiche prestazionali e BufferCacheHitRatio prima di implementare il carico di lavoro in produzione.

BufferCacheHitRatio è un parametro specifici dell'istanza, pertanto istanze diverse all'interno dello stesso cluster possono avere valori BufferCacheHitRatio diversi a seconda della modalità di distribuzione delle letture tra le istanze primarie e di replica. Se il carico di lavoro operativo non è in grado di gestire gli aumenti periodici della latenza dal ripopolamento della cache del working set dopo l'esecuzione di query analitiche, ti consigliamo di provare a isolare la cache del buffer del carico di lavoro normale da quella delle query analitiche. Puoi ottenere il completo isolamento di BufferCacheHitRatio indirizzando le query operative all'istanza primaria e le query analitiche solo alle istanze di replica. Puoi inoltre ottenere l'isolamento parziale indirizzando le query analitiche a un'istanza di replica specifica, con la consapevolezza che una percentuale di query regolari verrà eseguita anche su tale replica e potrebbe potenzialmente essere influenzata.

I valori appropriati di BufferCacheHitRatio dipendono dal caso d'uso e dai requisiti dell'applicazione. Non esiste un valore migliore o un valore minimo per questo parametro; solo tu puoi decidere se il compromesso rappresentato da un valore temporaneamente inferiore di BufferCacheHitRatio è accettabile dal punto di vista dei costi e delle prestazioni.

Utilizzo degli indici

Indici degli edifici

Quando importi dati in Amazon DocumentDB, devi creare i tuoi indici prima di importare set di dati di grandi dimensioni. Puoi utilizzare Amazon DocumentDB Index Tool per estrarre gli indici da un'istanza o mongodump directory MongoDB in esecuzione e crearli in un cluster Amazon DocumentDB. Per ulteriori informazioni sulle migrazioni, consulta Migrazione e aggiornamento di Amazon DocumentDB.

Selettività degli indici

Limita la creazione dell'indice ai campi in cui il numero di valori duplicati è inferiore all'1% del numero totale di documenti della raccolta. Ad esempio, se la raccolta contiene 100.000 documenti, creare solo indici nei campi in cui lo stesso valore si verifica al massimo 1000 volte.

La scelta di un indice con un numero elevato di valori univoci (ad esempio, un’elevata cardinalità) garantisce che le operazioni di filtro restituiscano un numero ridotto di documenti, ottenendo così buone prestazioni durante le scansioni degli indici. Un esempio di indice ad elevata cardinalità è un indice univoco, che garantisce che i predicati di uguaglianza restituiscano al massimo un singolo documento. Esempi di bassa cardinalità includono un indice su un campo booleano e un indice nel giorno della settimana. A causa delle scarse prestazioni, è improbabile che gli indici a bassa cardinalità vengano scelti dall'ottimizzatore delle query del database. Allo stesso tempo, gli indici a bassa cardinalità continuano a consumare risorse come spazio su disco e. I/Os Come regola generale, occorre indicare indici su campi in cui la frequenza tipica del valore è l'1% della dimensione totale della raccolta.

Inoltre, è consigliabile creare solo indici su campi comunemente utilizzati come un filtro e cercare regolarmente indici inutilizzati. Per ulteriori informazioni, consulta Come posso analizzare l'utilizzo degli indici e identificare gli indici inutilizzati?.

Impatto degli indici sulla scrittura dei dati

Sebbene gli indici possano migliorare le prestazioni delle query evitando la necessità di eseguire la scansione di tutti i documenti di una raccolta, questo miglioramento comporta un compromesso. Per ogni indice di una raccolta, ogni volta che un documento viene inserito, aggiornato o eliminato, il database deve aggiornare la raccolta e scrivere i campi in ciascuno degli indici per la raccolta. Ad esempio, se una raccolta dispone di nove indici, il database deve eseguire dieci scritture prima di riconoscere l'operazione al client. Pertanto, ogni indice aggiuntivo comporta una latenza di scrittura aggiuntiva e un aumento I/O dello spazio di archiviazione complessivo utilizzato.

Le istanze del cluster devono essere dimensionate in modo appropriato per mantenere tutta la memoria del set di lavoro. Ciò evita la necessità di leggere continuamente le pagine di indice dal volume di archiviazione, il che influisce negativamente sulle prestazioni e genera costi più elevati. I/O Per ulteriori informazioni, consulta Dimensionamento delle istanze.

Per ottenere prestazioni ottimali, ridurre al minimo il numero di indici nelle raccolte, aggiungendo solo gli indici necessari per migliorare le prestazioni per le query comuni. Mentre i carichi di lavoro variano, una buona linea guida consiste nel mantenere il numero di indici per raccolta a cinque o meno.

Identificazione degli indici mancanti

Come best practice, identificare regolarmente gli indici mancanti. Per ulteriori informazioni, consulta Come faccio a identificare gli indici mancanti?.

Identificazione degli indici non utilizzati

Come best practice, è consigliabile identificare e rimuovere regolarmente gli indici inutilizzati. Per ulteriori informazioni, consulta Come posso analizzare l'utilizzo degli indici e identificare gli indici inutilizzati?.

Best practice di sicurezza

Per le migliori pratiche di sicurezza per Amazon DocumentDB, consulta. Le migliori pratiche di sicurezza per Amazon DocumentDB

Ottimizzazione dei costi

Le seguenti best practice possono aiutarti a gestire e ridurre al minimo i costi di utilizzo di Amazon DocumentDB. Per informazioni sui prezzi, consulta le domande frequenti su Amazon DocumentDB (con compatibilità MongoDB) e Amazon DocumentDB (con compatibilità MongoDB).

• Crea avvisi di fatturazione in corrispondenza delle soglie al 50% e 75% della fattura mensile attesa. Per ulteriori informazioni sulla creazione di avvisi di fatturazione, consulta Creazione di un allarme di fatturazione.

• L'architettura di Amazon DocumentDB separa lo storage dall'elaborazione, quindi anche un cluster a istanza singola è estremamente resistente. Il volume di storage del cluster replica i dati in sei modi su tre zone di disponibilità, garantendo una durabilità estremamente elevata indipendentemente dal numero di istanze nel cluster. Un tipico cluster di produzione dispone di tre o più istanze per fornire la disponibilità elevata. Tuttavia, puoi ottimizzare i costi utilizzando un cluster di sviluppo a istanza singola quando non è richiesta la disponibilità elevata.

• Per scenari di sviluppo e di test, arresta un cluster quando non è più necessario e avvialo quando lo sviluppo riprende. Per ulteriori informazioni, consulta Arresto e avvio di un cluster Amazon DocumentDB.

• Sia il TTL che i flussi di modifica si verificano quando i dati vengono scritti, letti I/O ed eliminati. Se queste funzionalità sono state abilitate ma non vengono utilizzate nell'applicazione, la disattivazione delle funzionalità può contribuire a ridurre i costi.

Utilizzo di parametri per identificare problemi a livello di prestazioni

Argomenti

• Visualizzazione dei parametri relativi alle prestazioni

• Impostazione di un allarme CloudWatch

• Valutazione dei parametri relativi alle prestazioni

• Valutazione dell'utilizzo delle istanze Amazon DocumentDB con metriche CloudWatch

• Ottimizzazione di query

Per identificare i problemi di prestazioni causati da risorse insufficienti e altri colli di bottiglia comuni, puoi monitorare le metriche disponibili per il tuo cluster Amazon DocumentDB.

Visualizzazione dei parametri relativi alle prestazioni

Monitora regolarmente i parametri relativi alle prestazione per osservare i valori medi, massimi e minimi per vari intervalli di tempo. Ciò ti consente di identificare quando le prestazioni subiscono un calo. Puoi anche impostare CloudWatch allarmi Amazon per soglie metriche particolari in modo da essere avvisato se vengono raggiunte.

Per risolvere i problemi relativi alle prestazioni, è importante comprendere le prestazioni di base del sistema. Quando configuri un nuovo cluster e lo esegui con un carico di lavoro tipico, acquisisci il valore medio, massimo e minimo di tutti i parametri relativi alle prestazioni a intervalli diversi (ad esempio, un'ora, 24 ore, una settimana, due settimane). Ciò ti permette di avere un quadro dei valori normali. Ciò aiuta anche a effettuare confronti delle attività durante le ore di punta e non di punta. Puoi quindi utilizzare queste informazioni per identificare quando le prestazioni scendono al di sotto dei livelli standard.

Puoi visualizzare le metriche delle prestazioni utilizzando o. Console di gestione AWS AWS CLI Per ulteriori informazioni, consulta Visualizzazione CloudWatch dei dati.

Impostazione di un allarme CloudWatch

Per impostare un CloudWatch allarme, consulta Using Amazon CloudWatch Alarms nella Amazon CloudWatch User Guide.

Valutazione dei parametri relativi alle prestazioni

Un'istanza ha diverse categorie di parametri. La modalità di determinazione dei valori accettabili dipende dal parametro.

CPU

• Utilizzo della CPU: percentuale della capacità di elaborazione del computer utilizzata.

Memoria

• Memoria liberabile: quanta RAM è disponibile nell'istanza.

• Utilizzo dello swap: quanto spazio di swap viene utilizzato dall'istanza, in megabyte.

Input/output operazioni

• Read IOPS, Write IOPS: il numero medio di operazioni di lettura o scrittura su disco al secondo.

• Latenza di lettura, latenza di scrittura: il tempo medio di un'operazione di lettura o scrittura in millisecondi.

• Velocità effettiva di lettura, velocità effettiva di scrittura: il numero medio di megabyte letti o scritti su disco al secondo.

• Profondità della coda del disco: il numero di I/O operazioni in attesa di essere scritte o lette dal disco.

Traffico di rete

• Throughput di ricezione di rete, Throughput di trasmissione di rete: la velocità del traffico di rete da e verso l'istanza in megabyte al secondo.

Connessioni database

• Connessioni DB: il numero di sessioni client connesse all'istanza.

In generale, i valori accettabili per i parametri relativi alle prestazioni dipendono dalla baseline e dall'attività dell'applicazione. Indagare le variazioni della baseline coerenti o che rappresentano dei trend.

Di seguito sono riportati alcuni suggerimenti su tipi di parametri specifici:

• Consumo elevato di CPU: valori elevati per il consumo di CPU potrebbero essere appropriati, a condizione che siano in linea con gli obiettivi dell'applicazione (come la velocità effettiva o la concorrenza) e siano previsti. Se il consumo della CPU supera costantemente l'80%, valuta la possibilità di aumentare le dimensioni delle istanze.

• Consumo elevato di RAM: se la FreeableMemory metrica scende spesso al di sotto del 10% della memoria totale dell'istanza, valuta la possibilità di aumentare le istanze. Per ulteriori informazioni su cosa succede quando l'istanza DocumentDB presenta una pressione di memoria elevata, consulta Amazon DocumentDB Resource Governance.

• Utilizzo degli swap: questa metrica deve rimanere pari o prossima allo zero. Se l'utilizzo di swap è significativo, valuta la possibilità di aumentare le dimensioni delle istanze.

• Traffico di rete: per il traffico di rete, contatta l'amministratore di sistema per capire qual è il throughput previsto per la rete di dominio e la connessione Internet. Indaga il traffico di rete se il throughput è costantemente al di sotto del valore previsto.

• Connessioni al database: valuta la possibilità di limitare le connessioni al database se riscontri un numero elevato di connessioni utente e una diminuzione delle prestazioni delle istanze e dei tempi di risposta. Il numero ideale di connessioni utente per l'istanza dipende dalla classe di istanza e dalla complessità delle operazioni eseguite. In caso di problemi con i parametri relativi alle prestazioni, per migliorare la situazione puoi provare a ottimizzare le query più utilizzate e costose per verificare se ciò riduce la pressione sulle risorse di sistema.

Se le tue query sono ottimizzate e il problema persiste, valuta la possibilità di aggiornare la tua classe di istanza Amazon DocumentDB a una classe con più risorse (CPU, RAM, spazio su disco, larghezza di banda di rete, I/O capacità) correlate al problema riscontrato.

Valutazione dell'utilizzo delle istanze Amazon DocumentDB con metriche CloudWatch

Puoi utilizzare le CloudWatch metriche per monitorare il throughput dell'istanza e scoprire se la classe di istanze fornisce risorse sufficienti per le tue applicazioni. Per informazioni sulle quote delle classi di istanze, consulta Quote delle istanze e individua le specifiche della classe di istanza per determinare le prestazioni della tua rete.

Se l'utilizzo dell'istanza è vicino al limite della classe di istanza, le prestazioni potrebbero iniziare a rallentare. Le CloudWatch metriche possono confermare questa situazione, quindi puoi pianificare di passare manualmente a una classe di istanze più ampia.

Combina i seguenti valori CloudWatch delle metriche per scoprire se ti stai avvicinando al limite della classe di istanze:

• NetworkThroughput—La quantità di throughput di rete ricevuta e trasmessa dai client per ogni istanza nel cluster Amazon DocumentDB. Questo valore di throughput non include il traffico di rete tra le istanze del cluster e il volume di storage del cluster.

• StorageNetworkThroughput—La quantità di throughput di rete ricevuta e inviata al volume di storage del cluster Amazon DocumentDB da ciascuna istanza del cluster Amazon DocumentDB.

Aggiungilo NetworkThroughput a per trovare il StorageNetworkThroughput throughput di rete ricevuto e inviato al volume di storage del cluster Amazon DocumentDB da ciascuna istanza del tuo cluster Amazon DocumentDB. Il limite della classe dell’istanza deve essere maggiore della somma di questi due parametri combinati.

È possibile utilizzare i seguenti parametri per esaminare ulteriori dettagli del traffico di rete proveniente dalle applicazioni client durante l’invio e la ricezione:

• NetworkReceiveThroughput—La quantità di throughput di rete ricevuta dai client da ciascuna istanza nel cluster Amazon DocumentDB. Questo throughput non include il traffico di rete tra le istanze del cluster e il volume di storage del cluster.

• NetworkTransmitThroughput—La quantità di throughput di rete inviata ai client da ciascuna istanza del cluster Amazon DocumentDB. Questo throughput non include il traffico di rete tra le istanze del cluster e il volume di storage del cluster.

• StorageNetworkReceiveThroughput—La quantità di throughput di rete ricevuta dal volume di storage del cluster Amazon DocumentDB da ciascuna istanza del cluster.

• StorageNetworkTransmitThroughput—La quantità di throughput di rete inviata al volume di storage del cluster Amazon DocumentDB da ciascuna istanza del cluster.

Somma tutti questi parametri per confrontare l’utilizzo della rete e il limite della classe di istanza. Il limite della classe di istanza deve essere maggiore della somma di questi parametri combinati.

I limiti di rete e l'utilizzo della CPU da parte di un'istanza sono reciproci. quando la velocità di trasmissione effettiva della rete aumenta, cresce anche l’utilizzo della CPU. Il monitoraggio dell’utilizzo della CPU e della rete fornisce informazioni su come e perché le risorse vengono esaurite.

Per ridurre al minimo l’utilizzo della rete, puoi prendere in considerazione:

• L’uso di una classe di istanza più grande.

• La suddivisione delle richieste di scrittura in batch per ridurre le transazioni in generale.

• L’instradamento del carico di lavoro di sola lettura a un’istanza di sola lettura.

• L’eliminazione degli indici non utilizzati.

Ottimizzazione di query

Uno dei modi migliori per migliorare le prestazioni di un cluster consiste nell'ottimizzare le query più comuni e a uso più intensivo di risorse per renderle meno costose da eseguire.

Puoi utilizzare il profiler (vedi Profilazione delle operazioni di Amazon DocumentDB) per registrare il tempo di esecuzione e i dettagli delle operazioni eseguite nel cluster. Il profiler è utile per monitorare le operazioni più lente sul cluster per aiutare a migliorare le prestazioni delle singole query e le prestazioni complessive del cluster.

Puoi inoltre utilizzare il comando explain per informazioni su come analizzare un piano di query per una determinata query. Utilizza queste informazioni per modificare una query o una raccolta sottostante in modo da migliorare le prestazioni della query (ad esempio, aggiungendo un indice).

Carichi di lavoro TTL e serie temporali

L'eliminazione del documento risultante dalla scadenza dell'indice TTL è un processo di best effort. L'eliminazione dei documenti entro un termine specifico non è garantita. Fattori come la dimensione dell'istanza, l'utilizzo delle risorse dell'istanza, la dimensione del documento, il throughput complessivo, il numero di indici e il fatto che gli indici e il working set si adattino o meno nella memoria possono influenzare i tempi di eliminazione dei documenti scaduti dal processo TTL.

Quando il monitor TTL elimina i documenti, ogni cancellazione comporta dei I/O costi, il che comporta un aumento della fattura. Se la velocità effettiva e i tassi di eliminazione TTL aumentano, dovresti aspettarti una fattura più elevata a causa del maggiore utilizzo. I/O Tuttavia, se non si crea un indice TTL per eliminare i documenti, ma si segmentano i documenti in raccolte in base al tempo e si eliminano semplicemente le raccolte quando non sono più necessarie, non si incorre in alcun costo di I/O. Questo può essere molto più conveniente rispetto all'utilizzo di un indice TTL.

Per i carichi di lavoro di serie temporali, puoi prendere in considerazione la creazione di raccolte continue anziché di un indice TTL, poiché le raccolte cumulative possono essere un modo migliore e meno impegnativo per eliminare i dati. I/O Se disponi di raccolte di grandi dimensioni (in particolare raccolte superiori a 1 TB) o I/O i costi di eliminazione TTL sono un problema, suddividi i documenti in raccolte in base al tempo ed elimina le raccolte quando i documenti non sono più necessari. Puoi creare una raccolta al giorno o alla settimana, a seconda della frequenza di inserimento dei dati. Anche se i requisiti variano a seconda dell'applicazione, una buona regola generale è quella di avere raccolte più piccole piuttosto che alcune raccolte di grandi dimensioni. L'eliminazione di queste raccolte non comporta I/O costi e può essere più rapida e conveniente rispetto all'utilizzo di un indice TTL.

Migrazioni

Come best practice per la migrazione dei dati su Amazon DocumentDB, crea prima i tuoi indici in Amazon DocumentDB e poi migra i tuoi dati. Creando per primi gli indici, si riduce il tempo complessivo e si aumenta la velocità della migrazione. A tale scopo, puoi utilizzare Amazon DocumentDB Index Tool. https://github.com/awslabs/amazon-documentdb-tools Per ulteriori informazioni sulle migrazioni, consulta il. Migrazione e aggiornamento di Amazon DocumentDB

Si consiglia inoltre, prima di migrare il database di produzione, di testare completamente l'applicazione su Amazon DocumentDB, prendendo in considerazione funzionalità, prestazioni, operazioni e costi.

Lavorare con i gruppi di parametri del cluster

Prova le modifiche ai gruppi di parametri del cluster su un cluster di test prima di applicarle ai cluster di produzione. Per ulteriori informazioni sul backup di un cluster, consulta Backup e ripristino in Amazon DocumentDB.

Interrogazioni sulla pipeline di aggregazione

Quando crei una query di pipeline di aggregazione con più fasi e valuti solo un sottoinsieme dei dati nella query, utilizza la fase $match come prima fase o all'inizio della pipeline. Utilizzando prima $match ridurrai il numero di fasi successive dei documenti all'interno della query di pipeline di aggregazione che sarà necessario elaborare, migliorando così le prestazioni della query.

BatchInsert e BatchUpdate

Quando si esegue una frequenza elevata di batchInsert and/or batchUpdate operazioni simultanee e la quantità di FreeableMemory (CloudWatch Metric) va a zero sull'istanza principale, è possibile ridurre la concorrenza del carico di lavoro di inserimento o aggiornamento del batch oppure, se la concorrenza del carico di lavoro non può essere ridotta, aumentare la dimensione dell'istanza per aumentare la quantità di. FreeableMemory