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 per i cluster elastici di Amazon DocumentDB
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 read/update /delete per evitare le query scatter gather.
Evita le chiavi shard annidate quando esegui le operazioni /delete. read/update
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 il numero di vCPU per shard) per aumentare l'elaborazione è preferibile all'aumento o alla diminuzione del numero di shard-count, poiché è più veloce e presenta una durata più breve degli errori intermittenti del database e della rete.
Quando si prevede una crescita, è preferibile aumentare il numero di frammenti 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.
La modifica del numero di shard può richiedere tempo perché i dati devono essere spostati in modo sicuro da uno shard all'altro. Per ridurre al minimo il rischio di errori, si consiglia di non interrompere o apportare altre modifiche allo stato del cluster mentre la modifica è in corso.
Monitoraggio dei cluster elastici
L'elenco seguente descrive le linee guida per il monitoraggio dei cluster elastici.
-
Tieni traccia del rapporto tra picco e media delle tue metriche per shard per determinare se stai generando un traffico irregolare (se hai un hot spot). key/hot Le metriche chiave per tenere traccia del rapporto tra picco e media sono:
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.
