Versions du moteur et mise à niveau dans ElastiCache

• Jusqu'à 20 % de réduction de la mémoire pour les modèles de chaînes courants — Les chaînes de moins de 128 octets utilisent désormais 20 % de mémoire en moins. Les ensembles triés enregistrent une réduction de mémoire allant jusqu'à 10 %. Les opérations de suppression en bloc (SREM, ZREM, HDEL) interrompent la réduction automatique pendant les opérations en masse pour une exécution plus rapide.

• Commandes HGETDEL, MSETEX et CLUSTERSCAN — Trois nouvelles commandes : récupère et supprime de HGETDEL manière atomique les champs de hachage, MSETEX définit plusieurs clés avec une expiration partagée en un seul appel et permet une analyse des clés à l'échelle du cluster sur tous les nœuds. CLUSTERSCAN

• Database-level Contrôle d'accès ACL  : Per-database les autorisations via ACL SETUSER ... db=0,1 la syntaxe vous offrent un contrôle d'accès précis au niveau de la base de données pour les charges de travail multi-locataires sur un seul cluster.

• Plus de 70 améliorations supplémentaires, notamment la réduction des pics de latence liés au rehachage, le champ de zone de disponibilité CLUSTER SHARDS, les NX/XX indicateurs HSETEX, l'horloge matérielle activée par défaut, le format de journalisation JSON et les mesures d'utilisation cumulée des threads via INFO ALL. main/IO Pour la liste complète, consultez les notes de version de Valkey 9.1.

• Durabilité  : ElastiCache la version 9.0 de Valkey introduit la durabilité via un journal Multi-AZ transactionnel. Choisissez entre des écritures synchrones (aucune perte de données, latence d'écriture d'une milliseconde à un chiffre) ou des écritures asynchrones (latence d'écriture en microsecondes, jusqu'à 10 secondes de données à risque). La durabilité permet ElastiCache de servir de magasin de données pour les charges de travail du système d'enregistrement.

• Full-text recherche, agrégations et recherche hybride  : la ElastiCache version 9.0 pour Valkey étend les fonctionnalités de recherche introduites dans Valkey 8.2 avec la recherche en texte intégral, les pipelines d'agrégation et les requêtes hybrides qui combinent des résultats textuels et vectoriels. Créez des expériences de recherche puissantes directement dans votre cache sans avoir à gérer un moteur de recherche distinct. Ces fonctionnalités sont basées sur le projet open source valkey-search.

• Expiration des champs de hachage  : définissez des TTL pour les champs individuels d'un hachage, ce qui vous permet de contrôler avec précision le cycle de vie des données sans gérer de clés distinctes. Expirez automatiquement les champs périmés tout en conservant le reste du hachage intact. (#2089)

• Multi-database prise en charge en mode cluster — Utilisez des bases de données numérotées (SELECT 0—15) dans les configurations compatibles avec le mode cluster, supprimant ainsi une limitation de longue date et simplifiant les migrations depuis des déploiements autonomes vers des clusters à échelle horizontale. (#1671)

• Débit jusqu'à 40 % supérieur grâce au pipeline  : l'analyse et la prélecture optimisées des commandes dans les requêtes en pipeline permettent d'obtenir un débit nettement plus élevé pour les charges de travail chargées par lots, ce qui vous permet de traiter plus d'opérations par seconde sans ajouter de nœuds. (#2092)

• Polygon-based requêtes géospatiales  : BYPOLYGON cette nouvelle option vous GEOSEARCHSTORE permet d'interroger des membres à GEOSEARCH l'intérieur de limites de polygones arbitraires, ce qui permet des cas d'utilisation du géorepérage dans le monde réel, tels que les zones de livraison, les zones de desserte et le ciblage régional. (#1809)

• Plus de 100 améliorations supplémentaires apportées aux versions 9.0.0 à 9.0.3, dont 13 nouvelles fonctionnalités, 16 optimisations des performances avec accélération SIMD, la prise en charge de DELIFEQ, une observabilité étendue avec des métriques par nœud et par emplacement, la prise en charge du réseau MPTCP et une authentification automatique basée sur des certificats TLS. Pour la liste complète, consultez les notes de version de Valkey 9.0.

• ElastiCache for Valkey v8.2 fournit un support natif pour la recherche vectorielle, offrant une latence aussi faible que quelques microsecondes. Il s'agit de la recherche vectorielle la plus faible avec le débit le plus élevé et le meilleur rapport prix/performances avec un taux de rappel de plus de 95 % parmi les bases de données vectorielles les plus populaires sur. AWS

• Une nouvelle implémentation de table de hachage qui réduit la charge de mémoire afin de réduire l'utilisation de la mémoire jusqu'à 20 % pour les key/value modèles courants.

• Prise en charge native des filtres Bloom, un nouveau type de données qui vous permet d'effectuer des recherches en utilisant jusqu'à 98 % de mémoire en moins par rapport au type de données Set.

• Nouvelle commande COMMANDLOG qui enregistre les exécutions lentes, les demandes volumineuses et les réponses volumineuses.

• Nouvelle prise en charge de la mise à jour conditionnelle de la commande SET à l'aide de l'argument IFEQ.

• Améliorations des performances, notamment une latence jusqu'à 45 % inférieure pour la commande ZRANK, des performances jusqu'à 12 fois plus rapides pour PFMERGE et PFCOUNT, et un débit jusqu'à 514 % supérieur pour BITCOUNT.

• Améliorations de l'efficacité de la mémoire, permettant aux utilisateurs de stocker jusqu'à 20 % de données supplémentaires par nœud sans aucune modification de l'application.

• Newly-introduced infrastructure de métriques par emplacement pour les clusters basés sur des nœuds, offrant une visibilité détaillée des performances et de l'utilisation des ressources des emplacements individuels.

• ElastiCache Serverless for Valkey 8.0 peut doubler les demandes par seconde (RPS) prises en charge toutes les 2 à 3 minutes, atteignant 5 millions de RPS par cache, passant de zéro à moins de 13 minutes, avec une latence de lecture constante inférieure à la milliseconde p50.

• Optimisations des performances et de la mémoire pour différents types de données : optimisation de la mémoire pour les clés de type liste et d'ensemble, optimisation de la vitesse pour les commandes d'ensembles triés, optimisation des performances pour les commandes à touches multiples en mode cluster, améliorations des pub/sub performances, optimisation des performances pour les commandes SCAN, SSCAN, HSCAN, ZSCAN et de nombreuses autres petites optimisations.

• Nouvelle option WITHSCORE pour les commandes ZRANK et ZREVRANK

• CLIENT NO-TOUCH permettant aux clients d'exécuter des commandes sans affecter LRU/LFU les touches.

• Nouvelle commande CLUSTER MYSHARDID qui renvoie l'ID de partition du nœud pour regrouper logiquement les nœuds en mode cluster en fonction de la réplication.

• ElastiCache version 7.1 pour Redis OSS (améliorée)

• Fonctions  : ElastiCache pour Redis OSS 7 ajoute la prise en charge des fonctions Redis OSS et fournit une expérience gérée permettant aux développeurs d'exécuter des scripts LUA avec la logique d'application stockée sur le ElastiCache cluster, sans que les clients aient à renvoyer les scripts au serveur à chaque connexion.

• Améliorations des listes de contrôle d'accès  : Valkey et Redis OSS 7 ajoutent la prise en charge de la prochaine version des listes de contrôle d'accès (ACL). Les clients peuvent désormais spécifier plusieurs ensembles d'autorisations sur des clés ou des espaces clés spécifiques dans Valkey et Redis OSS.

• Sharded Pub/Sub  : ElastiCache pour Valkey et Redis OSS 7 ajoute la prise en charge de l'exécution des Pub/Sub fonctionnalités de manière partitionnée lors de l'exécution ElastiCache en mode cluster activé (CME). Pub/Sub les fonctionnalités permettent aux éditeurs d'envoyer des messages à un nombre illimité d'abonnés sur une chaîne. Les canaux sont liés à une partition du ElastiCache cluster, ce qui élimine le besoin de propager les informations des canaux entre les partitions, ce qui améliore l'évolutivité.

• I/O Multiplexage amélioré : ElastiCache pour Valkey et Redis, OSS 7 introduit un I/O multiplexage amélioré, qui fournit un débit accru et une latence réduite pour les charges de travail à haut débit qui ont de nombreuses connexions client simultanées à un cluster. ElastiCache Par exemple, lorsque vous utilisez un cluster de nœuds r6g.xlarge et que vous exécutez 5 200 clients simultanés, vous pouvez augmenter le débit jusqu'à 72 % (opérations de lecture et d'écriture par seconde) et réduire jusqu'à 71 % la latence P99, par rapport à la version 6 pour Redis OSS. ElastiCache

• Garantie de stabilité du moteur dans des conditions particulières

• Amélioration de la gestion des erreurs Hyperloglog

• Amélioration des commandes de liaison pour une réplication fiable

• Suivi continu de la diffusion des messages via la commande XCLAIM

• Amélioration de la gestion du champ LFU dans les objets

• Amélioration de la gestion des transactions en cas d'utilisation de ZPOP

• Possibilité de renommer les commandes : paramètre appelé rename-commands qui vous permet de renommer des commandes Redis OSS potentiellement dangereuses ou coûteuses susceptibles d'entraîner une perte de données accidentelle, telles que ou. FLUSHALL FLUSHDB Cette configuration est similaire à la configuration de la commande de changement de nom dans Redis OSS open source. Cependant, ElastiCache a amélioré l'expérience en fournissant un flux de travail entièrement géré. Les modifications des noms de commande sont appliquées immédiatement et propagées automatiquement sur tous les nœuds du cluster qui contiennent la liste de commandes. Vous n'avez pas besoin d'intervenir, par exemple en redémarrant les nœuds.

  Les exemples suivants montrent comment modifier les groupes de paramètres existants. Ils incluent le paramètre rename-commands, qui est une liste de commandes séparées par des espaces que vous souhaitez renommer.

  aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
  --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall restrictedflushall'" --region region
  

  Dans cet exemple, le paramètre rename-commands est utilisé pour renommer la commande flushall en restrictedflushall.

  Pour renommer plusieurs commandes, utilisez ce qui suit :

  aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
  --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall restrictedflushall flushdb restrictedflushdb''" --region region
  

  Pour annuler une modification, réexécutez la commande renommée et excluez les valeurs renommées de la liste ParameterValue que vous souhaitez conserver, comme illustré ci-après :

  aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
  --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall restrictedflushall'" --region region
  

  Dans ce cas, la commande flushall est renommée restrictedflushall et toutes les autres commandes renommées reprennent leur nom de commande initial.

  Note

  Lorsque vous renommez des commandes, vous devez respecter les limitations suivantes :

  • Toutes les commandes renommées doivent être alphanumériques.

  • La longueur maximale de nouveaux noms de commande est de 20 caractères alphanumériques.

  • Lorsque vous renommez des commandes, assurez-vous que vous mettez à jour le groupe de paramètres associé à votre cluster.

  • Pour empêcher une utilisation entière de la commande, utilisez le mot clé blocked, comme illustré ci-après :

    aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
    --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall blocked'" --region region
    

  Pour plus d'informations sur les modifications de paramètre et une liste des commandes qui sont éligibles pour renommer, consultez Modifications des paramètres de Redis OSS 5.0.3.

• Redis OSS Streams : il modélise une structure de données de journal qui permet aux producteurs d'ajouter de nouveaux éléments en temps réel. Il permet également aux consommateurs d'utiliser des messages, de façon bloquante ou non. Les flux permettent aussi aux groupes de consommateurs, qui représentent un groupe de clients, d'utiliser en collaboration différentes parties du même flux de messages, comme avec Apache Kafka. Pour plus d'informations, consultez Streams.

• Prise en charge d'une famille de commandes de flux, telles que XADD, XRANGE et XREAD. Pour plus d'informations, consultez la section Commandes de diffusion.

• Plusieurs paramètres nouveaux et renommés. Pour de plus amples informations, veuillez consulter Modifications des paramètres de Redis OSS 5.0.0.

• Une nouvelle métrique Redis OSS,StreamBasedCmds.

• Temps de capture légèrement plus rapide pour les nœuds Redis OSS.

• Garantie de stabilité du moteur dans des conditions particulières

• Amélioration de la gestion des erreurs Hyperloglog

• Amélioration des commandes de liaison pour une réplication fiable

• Suivi continu de la diffusion des messages via la commande XCLAIM

• Amélioration de la gestion du champ LFU dans les objets

• Amélioration de la gestion des transactions en cas d'utilisation de ZPOP

• Redis OSS Streams : il modélise une structure de données de journal qui permet aux producteurs d'ajouter de nouveaux éléments en temps réel. Il permet également aux consommateurs d'utiliser des messages, de façon bloquante ou non. Les flux permettent aussi aux groupes de consommateurs, qui représentent un groupe de clients, d'utiliser en collaboration différentes parties du même flux de messages, comme avec Apache Kafka. Pour plus d'informations, consultez Streams.

• Prise en charge d'une famille de commandes de flux, telles que XADD, XRANGE et XREAD. Pour plus d'informations, consultez la section Commandes de diffusion.

• Plusieurs paramètres nouveaux et renommés. Pour de plus amples informations, veuillez consulter Modifications des paramètres de Redis OSS 5.0.0.

• Une nouvelle métrique Redis OSS,StreamBasedCmds.

• Temps de capture légèrement plus rapide pour les nœuds Redis OSS.

• Redimensionnement et chiffrement des clusters en ligne dans une seule ElastiCache version. Pour plus d’informations, consultez les ressources suivantes :

  • Dimensionnement des clusters Valkey ou Redis OSS (mode cluster activé)

  • Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)

  • La sécurité des données sur Amazon ElastiCache

• Plusieurs nouveaux paramètres. Pour de plus amples informations, veuillez consulter Modifications des paramètres de Redis OSS 4.0.10.

• Prise en charge des familles de commandes de mémoire, comme MEMORY. Pour plus d'informations, voir Commandes (recherche sur MEMO).

• Prise en charge de la défragmentation de mémoire en ligne, tout en permettant une utilisation plus efficace de la mémoire et plus de mémoire disponible pour vos données.

• Prise en charge des vidanges et des suppressions asynchrones. ElastiCache pour Redis OSS prend en charge des commandes telles que UNLINK FLUSHDB et FLUSHALL pour s'exécuter dans un thread différent du thread principal. Cette étape aide à améliorer les performances et les temps de réponse pour vos applications en libérant de la mémoire de manière asynchrone.

• Une nouvelle métrique Redis OSS,ActiveDefragHits. Pour plus d'informations, consultez Metrics for Redis OSS.

• Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)

• Redimensionnement de cluster en ligne

• ElastiCache chiffrement en transit (TLS)

• At-Rest Chiffrement dans ElastiCache

• Validation de conformité pour Amazon ElastiCache

Remarques :

• Partitionnement : possibilité de fractionner vos données sur 2 à 500 groupes de nœuds (partitions) avec prise en charge de la réplication pour chaque groupe de nœuds.

• Indexation géospatiale — Redis OSS 3.2.4 introduit la prise en charge de l'indexation géospatiale via six commandes GEO. Pour plus d'informations, consultez la documentation de la commande Redis OSS GEO* Commands : GEO sur la page Valkey Commands (filtrée pour GEO).

• Migration de réplica

• Rééquilibrage du cluster

• Débogueur LUA

• cluster meet

• cluster replicate

• cluster flushslots

• cluster addslots

• cluster delslots

• cluster setslot

• cluster saveconfig

• cluster forget

• cluster failover

• cluster bumpepoch

• cluster set-config-epoch

• cluster reset

• Prise en charge des synchronisations et sauvegardes sans fonction fork, ce qui vous permet d'attribuer moins de mémoire pour les sauvegardes et plus de mémoire pour votre application. Le processus sans fonction fork peut avoir un impact sur la latence et le débit. Dans le cas d'un débit d'écriture élevé, lorsqu'un réplica relance une synchronisation, il peut être inaccessible pendant toute la durée de la synchronisation.

• En cas de basculement, les groupes de réplication récupèrent désormais plus rapidement, car les réplicas effectuent des synchronisations partielles avec le réplica principal plutôt que des synchronisations complètes, dans la mesure du possible. En outre, les réplicas principaux et les réplicas en lecture n'utilisent plus le disque pendant les synchronisations, permettant ainsi d'optimiser la vitesse.

• Prise en charge de deux nouvelles CloudWatch mesures.

  • ReplicationBytes : le nombre d'octets qu'un cluster principal du groupe de réplication envoie aux réplicas en lecture.

  • SaveInProgress : une valeur binaire qui indique si un processus de sauvegarde en arrière-plan est en cours d'exécution.

  Pour de plus amples informations, veuillez consulter Surveillance de l'utilisation à l'aide de CloudWatch métriques.

• Plusieurs correctifs de bogues essentiels dans le comportement de réplication PSYNC. Pour plus d'informations, consultez les notes de mise à jour de Redis OSS 2.8.

• Afin de maintenir des performances de réplication améliorées dans les groupes de Multi-AZ réplication et d'améliorer la stabilité du cluster, les ElastiCache non-répliques ne sont plus prises en charge.

• Pour améliorer la cohérence des données entre le cluster principal et les réplicas d'un groupe de réplication, les réplicas ne supprimeront plus les clés indépendantes du cluster principal.

• Les variables de configuration Redis OSS ne appendfsync sont pas prises en charge sur Redis OSS version 2.8.22 appendonly et versions ultérieures.

• En cas de mémoire insuffisante, les clients avec un important tampon de sortie peuvent être déconnectés d'un cluster de réplica. En cas de déconnexion, le client doit se reconnecter. Ces situations sont plus susceptibles de se produire pour les clients PUBSUB.

• Support pour HyperLogLog. Pour plus d'informations, consultez la section Nouvelle structure de données de Redis OSS : HyperLogLog.

• Le type de données « ensemble trié » prend désormais en charge les requêtes de plage lexicographiques avec les nouvelles commandes ZRANGEBYLEX, ZLEXCOUNT et ZREMRANGEBYLEX.

• Pour éviter qu'un nœud principal envoie des données obsolètes aux nœuds de réplica, la synchronisation principale échoue si un processus enfant (bgsave) d'enregistrement en arrière-plan est interrompu.

• Prise en charge de la HyperLogLogBasedCommands CloudWatch métrique. Pour de plus amples informations, veuillez consulter Métriques pour Valkey et Redis OSS.

• Résilience et tolérance aux pannes optimisées pour les réplicas en lecture.

• Prise en charge de la resynchronisation partielle.

• Prise en charge du nombre minimum de réplicas en lecture, défini par l'utilisateur, qui doit être disponible en permanence.

• Prise en charge complète de pub/sub —la notification aux clients des événements survenus sur le serveur.

• Détection automatique d'une défaillance du nœud principal et basculement de votre nœud principal vers un nœud secondaire.

• Rééquilibrage de section automatisé.

• Recherches plus rapides dans les tables de hachage avec l'algorithme murmur3.

• Algorithme LRU segmenté.

• Crawler LRU pour la récupération de mémoire d'arrière-plan

• --enable-seccomp : option pour la compilation.

• Correctifs cumulatifs, tels que les multigets ASCII CVE-2017-9951 et les explorations de limites pour. metadumper

• Meilleure gestion des connexions en fermant les connexions à la limite de connexion.

• Gestion améliorée de la taille d'élément pour une taille d'élément supérieure à 1 Mo.

• Meilleures performances et améliorations de la surcharge de mémoire en réduisant les besoins en mémoire par élément de quelques octets.

• Possibilité de vider toutes les métadonnées pour une classe de sections particulière, une liste de classes de sections ou toutes les classes de sections. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.31.

• Amélioration de la prise en charge pour les éléments volumineux dépassant la taille par défaut de 1 mégaoctet. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.29.

• Possibilité de spécifier pendant combien de temps un client peut rester inactif avant d'être invité à se fermer.

  Possibilité d'augmenter dynamiquement la quantité de mémoire disponible pour Memcached sans avoir à redémarrer le cluster. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.27.

• La journalisation de fetchers, mutations et evictions est désormais prise en charge. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.26.

• La mémoire libérée peut être récupérée dans un pool global et réaffectée à de nouvelles classes de sections. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.25.

• Plusieurs corrections de bugs.

• Quelques nouvelles commandes et paramètres. Pour en obtenir la liste, veuillez consulter Paramètres ajoutés Memcached 1.4.33.

• Une gestion de type LRU (Last Recently Used, moins récemment utilisé) à l'aide d'un processus d'arrière-plan.

• L'ajout de l'option d'utilisation de jenkins ou murmur3 en tant qu'algorithme de hachage.

• Quelques nouvelles commandes et paramètres. Pour en obtenir la liste, veuillez consulter Paramètres ajoutés Memcached 1.4.24.

• Plusieurs corrections de bugs.

• Capacité de rééquilibrage de section améliorée.

• Amélioration de l'évolutivité et des performances.

• L'ajout de la commande touch pour mettre à jour le délai d'expiration d'un élément existant sans avoir à l'extraire.

• Découverte automatique  : la possibilité pour les programmes client de déterminer automatiquement tous les nœuds de cache dans un cluster, et d'initier et maintenir des connexions à tous ces nœuds.