Scelta delle dimensioni dei nodi

Si prevedono carichi di lavoro legati al velocità di trasmissione effettiva con più connessioni client?

Se questo è il caso e utilizzi Valkey o Redis OSS dalla versione 5.0.6 alla 7.1, puoi ottenere un throughput e una latenza migliori con la funzionalità avanzata. I/O Le CPU disponibili scaricano le connessioni client dal motore. Se utilizzi Valkey, o Redis OSS dalla versione 7.0.4 alla 7.1, oltre a Enhanced, ottieni un'ulteriore accelerazione grazie al I/O multiplexing avanzato I/O, in cui ogni I/O thread di rete dedicato convoglia i comandi da più client nel motore, sfruttando la sua capacità di elaborare in modo efficiente i comandi in batch. A partire ElastiCache da Redis OSS v7.1 e Valkey 7.2, la funzionalità threads avanzata gestisce anche la logica del livello di presentazione. I/O Ciò significa che i I/O thread avanzati non solo leggono l'input del client, ma lo analizzano anche nel formato di comando binario del motore, che viene quindi inoltrato al thread principale per l'esecuzione, garantendo un aumento delle prestazioni. Per ulteriori informazioni, consulta il post del blog e la pagina delle versioni supportate.

Si dispone di carichi di lavoro che accedono regolarmente a una piccola percentuale dei dati?

Se questo è il caso e utilizzi la versione 6.2 o successiva del motore Redis OSS, puoi sfruttare il tiering dei dati scegliendo il tipo di nodo r6gd. Con il tiering di dati, i dati utilizzati meno di recente vengono archiviati su SSD. Quando vengono recuperati, è previsto un piccolo costo di latenza, bilanciato dai risparmi sui costi. Per ulteriori informazioni, consulta Suddivisione dei dati su più livelli ElastiCache.

Per ulteriori informazioni, consulta Tipi di nodi supportati.

Di quanta memoria in totale necessiti per i tuoi dati?

Per ottenere una stima generale, prendere la dimensione degli elementi che si desidera memorizzare nella cache. Moltiplicare questa dimensione per il numero degli elementi da conservare nella cache contemporaneamente. Per ottenere una stima veritiera delle dimensioni degli elementi, serializza gli elementi della cache e contane i caratteri. Poi dividi questo numero per il numero delle partizioni nel cluster.

Per ulteriori informazioni, consulta Tipi di nodi supportati.

Valkey e Redis OSS utilizzano un processo di salvataggio forkless per il failover, lo snapshot, la sincronizzazione e la promozione di una replica tra le operazioni primarie. Questo processo richiede meno memoria disponibile perché le scritture vengono gestite senza biforcare il processo.

Per ulteriori informazioni, consulta gli argomenti seguenti:

Quant'è consistente il carico di lavoro in scrittura della tua applicazione?

Le applicazioni caratterizzate da elevata attività di scrittura possono richiedere molta più memoria disponibile, non occupata dai dati, per acquisire snapshot o per il failover. Ogni volta che viene svolto il processo BGSAVE, è necessario disporre di memoria sufficiente che non viene utilizzata dai dati per contenere tutte le scritture che avvengono durante il processo BGSAVE Esempi sono quando si esegue uno snapshot, quando si sincronizza un cluster primario con una replica in un cluster e quando si abilita la caratteristica AOF (Append-only File). Un altro è quando si promuove una replica a primaria (se è stata Multi-AZ abilitata). Il caso peggiore è quando tutti i tuoi dati vengono riscritti durante il processo. In questo caso, è necessaria una dimensione di istanza di nodo con il doppio della memoria necessaria per i soli dati.

Per informazioni più dettagliate, consulta Assicurarsi di disporre di memoria sufficiente per creare un'istantanea OSS Valkey o Redis.

L'implementazione sarà un cluster Valkey o Redis OSS (modalità cluster disattivata) autonomo o un cluster Valkey o Redis OSS (modalità cluster abilitata) con più frammenti?

Cluster Valkey o Redis OSS (modalità cluster disattivata)

Se stai implementando un cluster Valkey o Redis OSS (modalità cluster disabilitata), il tipo di nodo deve essere in grado di contenere tutti i tuoi dati più l'overhead necessario, come descritto nel punto precedente.

Si supponga, ad esempio, di stimare che la dimensione totale di tutti gli articoli sia di 12 GB. In questo caso, puoi utilizzare un cache.m5.xlarge nodo con 12,93 GB di memoria o un cache.r5.large nodo con 13,07 GB di memoria. Tuttavia, potrebbe occorrere più memoria per le operazioni di BGSAVE. Se l'applicazione è pesante da scrivere, raddoppiare i requisiti di memoria fino ad almeno 24 GB. Pertanto, usa a cache.m5.2xlarge con 26,04 GB di memoria o a cache.r5.xlarge con 26,32 GB di memoria.

Valkey o Redis OSS (modalità cluster abilitata) con più frammenti

Se stai implementando un cluster Valkey o Redis OSS (modalità cluster abilitata) con più shard, il tipo di nodo deve essere in grado di contenere byte di dati. bytes-for-data-and-overhead / number-of-shards

Se, ad esempio, stimi in 12 GB la dimensione totale di tutti gli elementi e disponi di due partizioni. In questo caso, puoi utilizzare un cache.m5.large nodo con 6,38 GB di memoria (12 GB/2). Tuttavia, potrebbe occorrere più memoria per le operazioni di BGSAVE. Se l'applicazione è pesante da scrivere, raddoppiare i requisiti di memoria fino ad almeno 12 GB per partizioni. Pertanto, usa a cache.m5.xlarge con 12,93 GB di memoria o a cache.r5.large con 13,07 GB di memoria.

Stai usando Local Zones?

Le zone locali consentono di collocare risorse come un ElastiCache cluster in più posizioni vicino agli utenti. Tuttavia, quando si sceglie la dimensione del nodo, tenere presente che le dimensioni dei nodi disponibili sono limitate alle seguenti al momento, indipendentemente dai requisiti di capacità:

11 nodi cache.t2.medium, ciascuno con 3,22 GB di memoria e 2 thread = 35,42 GB e 22 thread.

6 nodi cache.m4.large, ciascuno con 6,42 GB di memoria e 2 thread = 38,52 GB e 12 thread.

3 nodi cache.r4.large, ciascuno con 12,3 GB di memoria e 2 thread = 36,90 GB e 6 thread.

3 nodi cache.m4.xlarge, ciascuno con 14,28 GB di memoria e 4 thread = 42,84 GB e 12 thread.