Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Best practice
Scopri le best practice per lavorare con i cluster elastici di Amazon DocumentDB. Tutte le best practice per i cluster Amazon DocumentDB basati su istanze si applicano anche ai cluster elastici. Questa sezione viene continuamente aggiornata man mano che vengono identificate nuove best practice.
Argomenti
Scelta delle chiavi condivise
L'elenco seguente descrive le linee guida per la creazione di chiavi shard.
Utilizza una chiave hash distribuita in modo uniforme per distribuire i dati su tutti gli shard del cluster (evita i tasti di scelta rapida).
Usa la tua chiave shard in tutte le richieste di lettura/aggiornamento/eliminazione per evitare le query di raccolta dispersione.
Evita le chiavi shard annidate quando esegui operazioni di lettura/aggiornamento/eliminazione.
Quando esegui operazioni batch, imposta su false
orderedin modo che tutti gli shard possano essere eseguiti in parallelo e migliorare le latenze.
Gestione delle connessioni
L'elenco seguente descrive le linee guida per la gestione delle connessioni al database.
Monitora il numero di connessioni e la frequenza con cui le nuove connessioni vengono aperte e chiuse.
Distribuisci le connessioni su tutte le sottoreti nella configurazione dell'applicazione. Se il cluster è configurato in più sottoreti ma ne utilizzi solo un sottoinsieme, potresti avere difficoltà a raggiungere il numero massimo di connessioni.
Raccolte non condivise
Di seguito viene descritta una linea guida per le raccolte non condivise.
Quando lavori con raccolte non condivise, per distribuire il carico, prova a conservare raccolte non condivise altamente utilizzate su database diversi. I cluster elastici di Amazon DocumentDB posizionano i database su diversi shard e colloca raccolte non condivise per lo stesso database sullo stesso shard.
Scalabilità dei cluster elastici
L'elenco seguente descrive le linee guida per la scalabilità dei cluster elastici.
Le operazioni di scalabilità possono causare un breve periodo di errori intermittenti del database e della rete. Quando possibile, evita il ridimensionamento durante le ore di punta. Prova a scalare durante le finestre di manutenzione.
La scalabilità verso l'alto e verso il basso della capacità degli shard (modificando v CPU count per shard) per aumentare la capacità di calcolo è preferibile all'aumento o alla diminuzione del numero di frammenti, poiché è più veloce e comporta una durata più breve degli errori intermittenti del database e della rete.
Quando si prevede una crescita, è preferibile aumentare il numero di shard anziché aumentare la capacità degli shard. Ciò consente di scalare il cluster aumentando la capacità degli shard per scenari in cui è necessario scalare rapidamente.
Monitora le politiche di riprova sul lato client e riprova con backoff e jitter esponenziali per evitare di sovraccaricare il database in caso di errori durante il ridimensionamento.
Monitoraggio dei cluster elastici
L'elenco seguente descrive le linee guida per il monitoraggio dei cluster elastici.
-
Tieni traccia del peak-to-average rapporto tra le tue metriche per shard per determinare se stai generando traffico irregolare (utilizza un tasto di scelta rapida/hot-spot). Le metriche chiave per monitorare i rapporti sono: peak-to-average
PrimaryInstanceCPUUtilizationQuesto può essere monitorato a livello di singolo shard.
A livello di cluster è possibile monitorare lo skew medio fino a p99.
PrimaryInstanceFreeableMemoryQuesto può essere monitorato a livello di singolo shard.
A livello di cluster è possibile monitorare lo skew medio fino a p99.
DatabaseCursorsMaxQuesto deve essere monitorato a livello di singolo shard per determinare l'inclinazione.
Documents-Inserted/Updated/Returned/DeletedQuesto deve essere monitorato a livello di singolo shard per determinare l'inclinazione.
