Best practice per i cluster elastici Amazon DocumentDB

Usa una chiave hash distribuita in modo uniforme per distribuire i tuoi 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 operazioni /delete. read/update

Quando esegui operazioni batch, imposta su false in modo ordered che tutti gli shard possano essere eseguiti in parallelo e migliorare le latenze.

Monitora il numero di connessioni e la frequenza con cui vengono aperte e chiuse nuove connessioni.

Distribuisci le connessioni su tutte le sottoreti nella configurazione dell'applicazione. Se il cluster è configurato in più sottoreti ma si utilizza solo un sottoinsieme delle sottoreti, è possibile che il numero massimo di connessioni consentite sia limitato.

Quando lavorate con raccolte non condivise, per distribuire il carico, provate a mantenere le raccolte non frammentate altamente utilizzate su database diversi. I cluster elastici di Amazon DocumentDB posizionano i database su diversi shard e co-localizzano le raccolte non frammentate per lo stesso database sullo stesso shard.

Le operazioni di scalabilità possono causare un breve periodo di errori intermittenti nel database e nella rete. Se possibile, evita il ridimensionamento nelle ore di punta. Provate a scalare durante le finestre di manutenzione.

È preferibile aumentare o diminuire la capacità degli shard (modificando il numero di vCPU per shard) per aumentare l'elaborazione rispetto all'aumento o alla diminuzione del numero di shard, poiché è più veloce e ha una durata inferiore degli errori intermittenti del database e della rete.

Quando si prevede una crescita, è preferibile aumentare il numero di shard anziché scalare la capacità degli shard. Ciò consente di scalare il cluster aumentando la capacità degli shard per gli scenari in cui è necessario scalare rapidamente.

Monitora le politiche relative ai tentativi sul lato client e riprova con backoff e jitter esponenziali per evitare di sovraccaricare il database in caso di errori durante la scalabilità.

La modifica del numero di shard può richiedere del tempo perché i dati devono essere spostati in modo sicuro da uno shard all'altro. Per ridurre al minimo il rischio di errori, non interrompere o apportare altre modifiche allo stato del cluster mentre la modifica è in corso.

Tieni traccia del rapporto tra picco e media delle tue metriche per shard per determinare se stai generando traffico irregolare (se hai un punto critico). key/hot Le metriche chiave per monitorare i rapporti tra picco e media sono: