Questions fréquentes Amazon MemoryDB

Amazon MemoryDB Multi-Region est une base de données multi-région entièrement gérée, active-active, qui vous permet de créer des applications avec une disponibilité allant jusqu’à 99,999 % et une latence de lecture d’une microseconde et d’une milliseconde d’écriture à un chiffre. Il assure la redondance des données dans plusieurs régions AWS, ce qui vous permet d’améliorer la disponibilité et la résilience de vos applications multi-régionales, même si le traitement d’une application est interrompu dans une région et ne peut pas se connecter à son point de terminaison MemoryDB. MemoryDB Multi-Region propose une réplication active-active afin que vous puissiez effectuer des lectures et des écritures localement depuis les régions les plus proches de vos clients avec une latence de lecture d’une microseconde et d’une milliseconde d’écriture d’un chiffre. Il réplique les données de manière asynchrone entre les régions, et les données sont généralement propagées en une seconde. MemoryDB Multi-Region résout automatiquement les conflits de mise à jour et corrige les problèmes de divergence des données, afin que vous puissiez vous concentrer sur votre application.

Vous pouvez utiliser MemoryDB Multi-Region si vous souhaitez créer des applications nécessitant les plus hauts niveaux de disponibilité, une résilience accrue et une meilleure continuité d’activité. MemoryDB Multi-Region peut également être utilisé si vous souhaitez créer et exécuter des applications multi-régions nécessitant un temps de réponse rapide partout dans le monde.

Lorsque vous utilisez MemoryDB Multi-Region, MemoryDB réplique les données sur des clusters régionaux dans une configuration appelée cluster multi-régional. Lorsque des données sont écrites sur un cluster régional au sein du cluster multi-régional, MemoryDB réplique automatiquement et de manière asynchrone ces données vers tous les autres clusters régionaux, généralement en une seconde, sans affecter les performances de votre application. MemoryDB Multi-Region résout automatiquement les conflits de mise à jour et corrige les problèmes de divergence des données. La résolution des conflits est entièrement gérée et se fait en arrière-plan sans aucun impact sur la disponibilité de l’application.

Pour commencer à utiliser MemoryDB Multi-Region, vous devez créer un nouveau cluster multi-régional et un cluster régional dans l’une des régions AWS de votre choix à l’aide de la console AWS, du SDK AWS ou de l’interface de ligne de commande. Une fois que vous avez créé le premier cluster régional, vous pouvez ajouter jusqu’à quatre régions supplémentaires au cluster multi-régional. Lorsque des données sont écrites sur un cluster régional, MemoryDB Multi-Region répliquera automatiquement ces données vers tous les autres clusters régionaux du cluster multi-régional, généralement en une seconde. Si vous utilisez MemoryDB aujourd’hui, vous pouvez prendre un instantané de votre cluster et l’utiliser pour créer un nouveau cluster multi-régional et un cluster régional.  

Vous pouvez ajouter de nouveaux clusters régionaux à un cluster MemoryDB Multi-Region en créant des clusters régionaux dans les régions AWS respectives. Cependant, vous ne pouvez pas ajouter un cluster MemoryDB existant à un cluster MemoryDB Multi-Region existant. Vous pouvez uniquement créer un nouveau cluster régional ou supprimer un cluster régional existant d’un cluster MemoryDB Multi-Region. Lorsque vous supprimez un cluster régional, MemoryDB Multi-Region supprime le cluster dans cette région spécifique tout en conservant le cluster MemoryDB Multi-Region. Les clients peuvent choisir d’ajouter ultérieurement d’autres clusters régionaux au sein du même cluster MemoryDB Multi-Region.

MemoryDB Multi-Region assure une cohérence finale car il effectue une réplication asynchrone, ce qui préserve les vitesses en mémoire. Toute mise à jour apportée à une clé de l’un des clusters MemoryDB Multi-Region est propagée de manière asynchrone aux autres clusters régionaux au sein du cluster Multi-Region de MemoryDB, généralement en moins d’une seconde.

MemoryDB Multi-Region utilise le type de données répliqué sans conflit (CRDT) pour réconcilier les écritures simultanées en conflit. Le CRDT est une structure de données qui peut être mise à jour indépendamment et simultanément sans coordination. Le conflit d’écriture-écriture est résolu indépendamment sur chaque réplique avec une cohérence éventuelle.

Si une région est isolée ou dégradée, MemoryDB Multi-Region enregistre toutes les écritures qu’elle a effectuées mais qui n’ont pas encore été propagées à tous les clusters régionaux. Lorsque la région est de nouveau en ligne, MemoryDB Multi-Region reprend la propagation des écritures en attente depuis cette région vers les clusters régionaux des autres régions. Il reprend également la propagation des écritures provenant d’autres clusters régionaux vers la région qui est désormais de nouveau en ligne. MemoryDB Multi-Region propage finalement toutes les écritures précédemment réussies, quelle que soit la durée pendant laquelle la région est isolée. Des conflits peuvent survenir si votre application met à jour la même clé dans différentes régions à peu près au même moment. MemoryDB Multi-Region utilise la réconciliation des types de données répliqués (CRDT) sans conflit entre les mises à jour simultanées. La résolution des conflits est entièrement gérée et se fait en arrière-plan sans aucun impact sur la disponibilité de l’application.

Le débit et la latence de MemoryDB varient en fonction du type de nœud, de la taille des données utiles et du nombre de connexions client. MemoryDB offre une latence de lecture de l’ordre de la microseconde, une latence d’écriture de l’ordre de la milliseconde et une latence de lecture après écriture sur le nœud primaire d’un cluster. MemoryDB peut prendre en charge jusqu’à 390 000 demandes de lecture et 100 000 demandes d’écriture par seconde et jusqu’à 1,3 Go/s de débit en lecture et 100 Mo/s en écriture par nœud (sur la base de tests internes sur des charges de travail en lecture seule et en écriture seule). Un cluster MemoryDB répartit les données sur un ou plusieurs nœuds, ce qui vous permet d’ajouter d’autres partitions ou réplica à votre cluster pour augmenter le débit global.

MemoryDB stocke l’ensemble de vos données en mémoire et utilise un journal transactionnel distribué multi-AZ pour offrir durabilité, cohérence et récupération des données. En stockant les données sur plusieurs AZ, MemoryDB permet une restauration et un redémarrage rapides de la base de données. En stockant également les données en mémoire, MemoryDB peut offrir des performances ultra-rapides et un débit élevé.

MemoryDB s’appuie sur un journal transactionnel distribué pour stocker durablement les données. En stockant les données sur plusieurs AZ, MemoryDB permet une restauration et un redémarrage rapides de la base de données. En outre, MemoryDB offre une cohérence éventuelle pour les nœuds de réplica et des lectures cohérentes sur les nœuds primaires.

Valkey et Redis OSS incluent une fonctionnalité de fichier en ajout uniquement (AOF) optionnelle, qui conserve les données dans un fichier sur le disque d’un nœud primaire pour en assurer la durabilité. Cependant, comme l’AOF stocke les données localement sur des nœuds primaires dans une seule zone de disponibilité, il y a des risques de perte de données. De plus, en cas de défaillance d’un nœud, il existe des risques de problèmes de cohérence avec les réplica.

Oui, MemoryDB prend en charge la haute disponibilité. Vous pouvez créer un cluster MemoryDB avec une disponibilité multi-AZ avec jusqu’à cinq réplica dans différentes zones de disponibilité. En cas de panne sur un nœud primaire, MemoryDB bascule automatiquement et promeut l’un des réplica pour qu’il serve de nouveau trafic principal et dirige le trafic d’écriture vers celui-ci. En outre, MemoryDB utilise un journal transactionnel distribué pour garantir la mise à jour des données des réplica, même en cas de défaillance d’un nœud primaire. Le basculement s’effectue généralement en moins de 20 secondes pour les pannes non planifiées et en moins de 200 millisecondes pour les pannes planifiées.

MemoryDB utilise un journal transactionnel distribué pour stocker durablement les données écrites dans votre base de données pendant la restauration de la base de données, le redémarrage, le basculement et la cohérence éventuelle entre les bases primaires et les réplica.

Valkey et Redis OSS permet des écritures et des lectures fortement cohérentes sur le nœud primaire de chaque partition et des lectures cohérentes à termes à partir de réplica de lecture. Ces propriétés de cohérence ne sont pas garanties en cas de défaillance d’un nœud primaire, car des écritures peuvent être perdues lors d’un basculement et violer ainsi le modèle de cohérence.

Le modèle de cohérence de MemoryDB est similaire à celui de Valkey et Redis OSS. En revanche, dans MemoryDB, les données ne sont pas perdues en cas de basculement, ce qui permet aux clients de lire leurs écritures à partir des nœuds primaires, indépendamment des défaillances des nœuds. Seules les données conservées avec succès dans le journal des transactions multi-AZ sont visibles. Les nœuds de réplica restent finalement cohérents, les métriques de décalage étant publiées sur Amazon CloudWatch.

Avec la version 7.0 de MemoryDB pour Redis OSS, nous avons introduit un multiplexage E/S amélioré, qui apporte des améliorations supplémentaires au débit et à la latence à grande échelle. La version 7.2 de MemoryDB pour Valkey prend également en charge le multiplexage E/S amélioré. Le multiplexage E/S amélioré est idéal pour les charges de travail limitées par le débit avec plusieurs connexions client, et ses avantages se mettent à l’échelle au niveau de la simultanéité des charges de travail. À titre d’exemple, en utilisant le nœud r6g.4xlarge et en exécutant 5200 clients simultanés, vous pouvez obtenir jusqu’à 46 % d’augmentation du débit (opérations de lecture et d’écriture par seconde) et jusqu’à 21 % de réduction de la latence P99, par rapport à MemoryDB version 6 pour Redis OSS. Pour ces types de charges de travail, le traitement des E/S réseau d'un nœud peut devenir un facteur limitant la capacité de mise à l'échelle. Grâce au multiplexage E/S amélioré, chaque thread d’E/S réseau dédié achemine les commandes de plusieurs clients vers les moteurs MemoryDB, en tirant parti de la capacité du moteur à traiter efficacement les commandes par lots.

Pour en savoir plus, consultez la documentation.

Pour écrire et lire des données dans votre cluster MemoryDB, vous vous connectez à votre cluster en utilisant l’un des clients Valkey ou Redis OSS pris en charge. Pour obtenir la liste des clients Valkey ou Redis OSS pris en charge, consultez la documentation Valkey ou Redis OSS. Pour savoir comment vous connecter à votre cluster MemoryDB à l’aide d’un client Valkey ou Redis OSS, consultez la documentation de MemoryDB. Valkey fonctionnera avec les clients Redis OSS existants ; vous n’avez donc pas besoin de changer de client lorsque vous passez de Redis OSS à Valkey.

Vous créez un cluster MemoryDB comprenant jusqu’à 500 nœuds. Cela donne une capacité de stockage mémoire maximale d’environ 100 To, en supposant que vous ayez 250 nœuds primaires avec chacun un réplica pour une haute disponibilité (500 nœuds au total).

Oui, vous pouvez redimensionner votre cluster MemoryDB horizontalement et verticalement. Vous pouvez mettre horizontalement à l’échelle votre cluster en ajoutant ou en supprimant des nœuds. Vous pouvez choisir d’ajouter des partitions pour répartir votre jeu de données sur un plus grand nombre de partitions, et vous pouvez ajouter des nœuds de réplica supplémentaires à chaque partition pour augmenter la disponibilité et le débit de lecture. Vous pouvez également supprimer des partitions et des réplica pour les adapter à votre cluster. En outre, vous pouvez mettre verticalement à l’échelle votre cluster verticalement en modifiant le type de nœud, ce qui modifie vos ressources de mémoire et de CPU par nœud. Pendant les opérations de redimensionnement horizontal et vertical, votre cluster reste en ligne et répond aux demandes de lecture et d’écriture.

MemoryDB facilite la maintenance et les mises à jour de votre cluster et propose deux processus différents pour la maintenance du cluster. Tout d’abord, pour certaines mises à jour obligatoires, MemoryDB corrige automatiquement votre cluster pendant les fenêtres de maintenance que vous spécifiez. Ensuite, pour certaines mises à jour, MemoryDB utilise des mises à jour de service, que vous pouvez appliquer à tout moment ou planifier pour une prochaine fenêtre de maintenance. Certaines mises à jour de service sont automatiquement planifiées dans une fenêtre de maintenance après une certaine date. Les mises à jour des clusters permettent de renforcer la sécurité, la fiabilité et les performances opérationnelles de vos clusters, et votre cluster reste en ligne et répond aux demandes de lecture et d’écriture. Pour plus d’informations sur la maintenance des clusters, consultez la documentation de MemoryDB.

Oui, vous créez des instantanés pour sauvegarder les données et les métadonnées de votre cluster MemoryDB. Vous pouvez créer un instantané manuellement ou utiliser le planificateur d’instantanés automatisé de MemoryDB pour prendre un nouvel instantané chaque jour à l’heure que vous spécifiez. Vous pouvez choisir de conserver votre instantané jusqu’à 35 jours après sa création, ainsi que MemoryDB. Les instantanés sont stockés dans Amazon S3 conçu pour une durabilité de 99,999999999 % (onze 9). Vous pouvez également choisir de prendre un instantané final de votre cluster lorsque vous le supprimez. En outre, vous pouvez exporter des instantanés MemoryDB depuis le service vers votre compartiment Amazon S3. Pour en savoir plus sur les instantanés, veuillez consulter la documentation de MemoryDB.

Oui, vous pouvez restaurer votre cluster MemoryDB à partir d’un instantané lors de la création d’un nouveau cluster MemoryDB.

Oui, vous pouvez restaurer votre cluster MemoryDB à partir d’un fichier Valkey ou Redis OSS RDB. Vous pouvez spécifier le fichier RDB à partir duquel effectuer la restauration lors de la création d’un nouveau cluster MemoryDB.

Oui, vous pouvez migrer des données d’ElastiCache vers MemoryDB. Commencez par créer un instantané de votre cluster ElastiCache et exportez-le vers votre compartiment S3. Créez ensuite un nouveau cluster MemoryDB et spécifiez la sauvegarde à partir de laquelle effectuer la restauration. MemoryDB va créer un cluster avec les données et les métadonnées Valkey ou Redis OSS de l’instantané. Pour plus d’informations sur la migration de données d’ElastiCache vers MemoryDB, consultez la documentation de MemoryDB.

Oui, MemoryDB propose des mesures opérationnelles et de performance pour votre cluster. MemoryDB dispose de plus de 30 métriques CloudWatch, que vous pouvez consulter dans la console MemoryDB. Pour plus d’informations sur les métriques CloudWatch et MemoryDB, consultez la documentation de MemoryDB.

Oui, MemoryDB prend en charge le chiffrement de vos données au repos et en transit. Pour le chiffrement au repos, vous pouvez utiliser les clés gérées par le client (CMK) AWS Key Management Service ou une clé fournie par MemoryDB. Avec les instances Graviton2 pour votre cluster MemoryDB, vos données sont chiffrées en mémoire à l’aide d’un chiffrement DRAM 256 bits constant.

MemoryDB utilise des listes de contrôle d’accès (ACL) afin de contrôler l’authentification et l’autorisation dans votre cluster. Les listes de contrôle d'accès (ACL) vous permettent de définir plusieurs autorisations pour plusieurs utilisateurs au sein du même cluster. Une ACL est une collection d’un ou de plusieurs utilisateurs. Chaque utilisateur dispose d’un mot de passe et d’une chaîne d’accès, qui sont utilisés pour autoriser l’accès aux commandes et aux données. Pour en savoir plus sur les ACL dans MemoryDB, consultez la documentation de MemoryDB.

Oui, tous les clusters MemoryDB doivent être lancés dans un VPC.

Nous continuerons à soutenir davantage de certifications de conformité. Cliquez ici pour obtenir les dernières informations sur la préparation à la conformité.

Oui. Pour obtenir un historique de tous les appels d’API Amazon MemoryDB réalisés sur votre compte, il suffit d’activer CloudTrail dans la console de gestion AWS. Pour plus d’informations, consultez la page d’accueil de CloudTrail.

La hiérarchisation des données pour Amazon MemoryDB est une nouvelle option de rapport prix/performance pour MemoryDB qui déplace automatiquement les données les moins fréquemment consultées de la mémoire vers des disques d’état solide (SSD) à haute performance et connectés localement. La hiérarchisation des données augmente la capacité, simplifie la gestion des clusters et améliore le coût total de possession (TCO) de MemoryDB.

Vous devez utiliser la hiérarchisation des données lorsque vous avez besoin d’un moyen plus simple et plus rentable d’augmenter la capacité de données de vos clusters MemoryDB sans sacrifier la disponibilité de vos applications. La hiérarchisation des données est idéale pour les charges de travail qui accèdent régulièrement à 20 % de leurs données et pour les applications qui peuvent tolérer une latence supplémentaire la première fois qu’un élément moins fréquemment consulté est nécessaire. L’utilisation de la hiérarchisation des données avec les nœuds R6gd qui ont environ cinq fois plus de capacité totale (mémoire + SSD) peut vous aider à réaliser plus de 60 % d’économies sur les coûts de stockage lorsqu’ils fonctionnent à l’utilisation maximale par rapport aux nœuds R6g (mémoire uniquement). En supposant des valeurs de chaîne de 500 octets, la latence supplémentaire s'élève à 450 µs en moyenne pour les demandes de lecture de données stockées sur SSD par rapport aux données en mémoire.

La hiérarchisation des données fonctionne en utilisant le stockage SSD dans les nœuds du cluster lorsque la capacité de mémoire disponible est épuisée. Lors de l’utilisation de nœuds de cluster dotés d’un stockage SSD, la hiérarchisation des données est automatiquement activée et MemoryDB gère le placement des données, en déplaçant de manière transparente les éléments entre la mémoire et le disque à l’aide d’une politique d’utilisation la moins récente (LRU). Lorsque la mémoire est complètement consommée, MemoryDB détecte automatiquement les éléments qui ont été utilisés le moins récemment et déplace leurs valeurs sur le disque, optimisant ainsi les coûts. Lorsqu’une application doit récupérer un élément sur le disque, MemoryDB déplace de manière transparente sa valeur en mémoire avant de servir la requête, avec un impact minimal sur les performances.

Pour commencer, créez un nouveau cluster MemoryDB en utilisant des instances à mémoire optimisée avec des processeurs AWS Graviton2 basés sur ARM et des disques SSD NVMe (R6gd). Vous pouvez ensuite migrer les données d’un cluster existant en important un instantané.

Les nœuds R6gd avec hiérarchisation des données sont basés sur le nombre d’heures d’instance consommées. Vous payez également pour les données écrites lorsque vous utilisez R6gd, comme pour les autres types de nœuds MemoryDB. Pour obtenir des informations supplémentaires, consultez la page de tarification MemoryDB.

Pour commencer, créez un nouveau cluster MemoryDB en utilisant des instances à mémoire optimisée avec des processeurs AWS Graviton2 basés sur ARM et des disques SSD NVMe (R6gd). Vous pouvez ensuite migrer les données d’un cluster existant en important un instantané.

Les nœuds réservés MemoryDB offrent une certaine flexibilité en termes de taille au sein d'une famille de nœuds et d'une région AWS. Cela signifie que le tarif réduit pour les nœuds réservés sera appliqué automatiquement à l'utilisation de toutes les tailles dans la même famille de nœuds. Par exemple, si vous achetez un nœud réservé r6g.xlarge et que vous devez passer à un nœud r6g.2xlarge plus volumineux, le tarif réduit de votre nœud réservé sera automatiquement appliqué à 50 % d’utilisation du nœud r6g.2xlarge dans la même Région AWS. Cette flexibilité en termes de taille réduira le temps que vous devrez consacrer à la gestion de vos nœuds réservés. Comme vous n’êtes plus lié à une taille de nœud de base de données spécifique, vous pouvez tirer le meilleur parti de votre remise, même si votre capacité a besoin de modifications.

La tarification des nœuds réservés MemoryDB est basée sur le type de nœud, la durée du contrat (un ou trois ans), le mode de paiement (aucun paiement initial, paiement partiel, paiement initial total) et la Région AWS. Veuillez noter que les prix des nœuds réservés ne couvrent pas les coûts des données écrites ou de stockage des instantanés. Pour obtenir des informations supplémentaires, consultez la page de tarification MemoryDB.

MemoryDB propose des nœuds réservés pour les nœuds R6g, R7g et R6gd optimisés pour la mémoire (avec hiérarchisation des données).

La recherche vectorielle pour MemoryDB permet de stocker des millions de vecteurs, avec des temps de réponse aux requêtes et aux mises à jour de l'ordre de la milliseconde, tout en atteignant un taux de rappel de plus de 99 %. La recherche vectorielle pour MemoryDB peut stocker des vecteurs que vous générez à partir de services tels qu’Amazon Bedrock et Amazon SageMaker.

Vous devez utiliser la recherche vectorielle pour MemoryDB lorsque vous créez des applications d’intelligence artificielle et de machine learning (IA/ML) à haut débit à l’aide de l’API MemoryDB. La recherche vectorielle pour MemoryDB est bien adaptée aux cas d’utilisation où les performances maximales constituent le critère de sélection le plus important. Depuis le 26 juin 2024, MemoryDB offre les performances de recherche vectorielle les plus rapides et les taux de rappel les plus élevés parmi les bases de données vectorielles les plus populaires sur AWS. Vous pouvez utiliser la recherche vectorielle pour MemoryDB pour alimenter des cas d’utilisation de ML et d’IA générative tels que la génération à enrichissement contextuel (RAG), la détection des anomalies (fraudes), les moteurs de recommandation en temps réel et la récupération de documents.

La configuration d’une application pilotée par l’IA et le ML dans un souci de rapidité peut entraîner une baisse de la qualité des réponses, mesurée à l’aide des taux de rappel. La recherche vectorielle pour MemoryDB offre le débit le plus élevé avec des temps de réponse aux requêtes et aux mises à jour de l’ordre de la milliseconde, sans compromettre le rappel en stockant les vecteurs en mémoire.

Avec la recherche vectorielle, vous pouvez stocker, indexer, récupérer et rechercher des vectorisations dans MemoryDB en même temps que vos données. Tout d’abord, vous générez des vectorisations directement via des modèles de vectorisation tels que Amazon Titan Embeddings ou via des services gérés tels qu’Amazon Bedrock. Ensuite, vous chargez les vectorisations dans MemoryDB après avoir initialisé votre index vectoriel à l’aide des API de plan de données MemoryDB. MemoryDB stocke les vectorisations sous forme de données JSON ou de hachage. 

Une fois chargé, MemoryDB construit l’index avec vos vectorisations. Lorsque vous chargez de nouvelles données, que vous mettez à jour des données existantes ou que vous les supprimez, MemoryDB transmet les mises à jour à l’index vectoriel en quelques millisecondes. MemoryDB prend en charge les requêtes de recherche efficaces, le préfiltrage et plusieurs métriques de distance (cosinus, produit scalaire et euclidien). Pour plus d’informations sur l’utilisation de la recherche vectorielle pour MemoryDB, consultez la documentation.

L’utilisation de la recherche vectorielle pour MemoryDB n’entraîne aucun coût supplémentaire. Pour en savoir plus, consultez la page Tarification MemoryDB.