Confronto tra le cache autoprogettate da Valkey, Memcached e Redis OSS

Scegliere Memcached per le seguenti esigenze:

• Hai bisogno del modello in assoluto più semplice.

• Hai necessità di eseguire grandi nodi con più core o thread.

• Hai la possibilità di dimensionare, aggiungere e rimuovere i nodi a seconda che la domanda del tuo sistema sia crescente o decrescente.

• Hai necessità di memorizzare gli oggetti nella cache.

Scegliete Valkey o Redis OSS con ElastiCache se vi si applica quanto segue:

• ElastiCache versione 7.2 per Valkey o versione 7.0 (Enhanced) per Redis OSS

  Desideri utilizzare i miglioramenti di Functions, Sharded Pub/Sub o ACL. Per ulteriori informazioni, consulta Redis OSS versione 7.0 (Enhanced).

• ElastiCache versione 6.2 (Enhanced) per Redis OSS

  Vuoi la possibilità di eseguire il livello dei dati tra memoria e SSD utilizzando il tipo di nodo r6gd. Per ulteriori informazioni, consulta la sezione Tiering di dati.

• ElastiCache versione 6.0 (Enhanced) per Redis OSS

  Vuoi autenticare gli utenti con il controllo accessi basato sui ruoli.

  Per ulteriori informazioni, consulta Redis OSS versione 6.0 (Enhanced).

• ElastiCache versione 5.0.0 (Enhanced) per Redis OSS

  Desideri utilizzare Redis OSS Streams, una struttura di dati di registro che consente ai produttori di aggiungere nuovi elementi in tempo reale e consente inoltre ai consumatori di utilizzare i messaggi in modo bloccante o non bloccante.

  Per ulteriori informazioni, consulta Redis OSS versione 5.0.0 (Enhanced).

• ElastiCache versione 4.0.10 (Enhanced) per Redis OSS

  Supporta sia la crittografia che l'aggiunta o la rimozione dinamica di shard dal cluster Valkey o Redis OSS (modalità cluster abilitata).

  Per ulteriori informazioni, consulta Redis OSS versione 4.0.10 (Enhanced).

• ElastiCache versione 3.2.10 (Enhanced) per Redis OSS

  Supporta la possibilità di aggiungere o rimuovere dinamicamente shard dal cluster Valkey o Redis OSS (modalità cluster abilitata).

  Importante

  Attualmente ElastiCache 3.2.10 per Redis OSS non supporta la crittografia.

  Per ulteriori informazioni, consulta gli argomenti seguenti:

  • Redis OSS versione 3.2.10 (avanzata)

  • Best practice di resharding online per Redis OSS. Per ulteriori informazioni, consulta quanto segue:

    • Best practice: resharding online

    • Resharding online e ribilanciamento degli shard per Valkey o Redis OSS (modalità cluster abilitata)

  • Per ulteriori informazioni sulla scalabilità dei cluster Redis OSS, consulta Scaling.

• ElastiCache versione 3.2.6 (Enhanced) per Redis OSS

  Se hai bisogno delle funzionalità delle versioni precedenti di Redis OSS oltre alle seguenti funzionalità, scegli 3.2.6:

  • Crittografia dei dati in transito Per ulteriori informazioni, consulta Amazon ElastiCache for Redis OSS In-Transit Encryption.

  • Crittografia dei dati inattivi Per ulteriori informazioni, consulta Amazon ElastiCache for Redis OSS At-Rest Encryption.

• ElastiCache (modalità cluster abilitata) versione 3.2.4 per Redis OSS

  Se hai bisogno della funzionalità della versione 2.8.x oltre alle seguenti funzionalità, scegli 3.2.4 (modalità cluster):

  • Hai la necessità di eseguire la partizione dei dati tra due fino a 500 gruppi di nodi (solo in modalità cluster).

  • Hai la necessità di effettuare l'indicizzazione geospaziale (modalità cluster o non-cluster).

  • Non è necessario il support di più database.

• ElastiCache (modalità non in cluster) 2.8.x e 3.2.4 (Enhanced) per Redis OSS

  Se si applica quanto segue, 2.8.x o 3.2.4 (modalità non in cluster):

  • Sono necessari tipi di dati complessi, ad esempio stringa, set, set ordinati, elenchi, hash e bitmap.

  • È necessario ordinare o classificare i dataset in-memory.

  • Il tuo store di chiavi deve essere permanente.

  • È necessario replicare i dati dai primari a quelli relativi a una o più repliche di lettura per applicazioni di letture intensive.

  • Se il primo nodo riporta un errore, è necessario un failover automatico.

  • È necessario pubblicare e sottoscrivere le caratteristica(pub/sub) per informare i clienti sugli eventi sul server.

  • Sono necessarie funzionalità di backup e ripristino per cluster progettati autonomamente e cache serverless.

  • È necessario il support di più database.