Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Sélectionnez un service de base de données pour vos applications basées sur Lambda
De nombreuses applications sans serveur ont besoin de stocker et de récupérer des données. AWS propose plusieurs options de base de données qui fonctionnent avec les fonctions Lambda. Les deux options les plus populaires sont Amazon DynamoDB, un service de base de données NoSQL, et Amazon RDS, une solution de base de données relationnelle traditionnelle. Les sections suivantes expliquent les principales différences entre ces services lorsque vous les utilisez avec Lambda et vous aident à sélectionner le service de base de données adapté à votre application sans serveur.
Pour en savoir plus sur les autres services de base de données proposés par AWS, et pour comprendre leurs cas d'utilisation et leurs inconvénients de manière plus générale, voir Choisir un service de AWS base de données. Tous les services de AWS base de données sont compatibles avec Lambda, mais ils ne sont peut-être pas tous adaptés à votre cas d'utilisation particulier.
Quels sont vos choix lorsque vous sélectionnez un service de base de données avec Lambda ?
AWS propose plusieurs services de base de données. Pour les applications sans serveur, DynamoDB et Amazon RDS sont deux des options les plus populaires.
-
DynamoDB est un service de base de données NoSQL entièrement géré optimisé pour les applications sans serveur. Il assure une mise à l'échelle fluide et des performances constantes à une milliseconde à un chiffre, quelle que soit l'échelle.
-
Amazon RDS est un service de base de données relationnelle géré qui prend en charge plusieurs moteurs de base de données, notamment MySQL et PostgreSQL. Il fournit des fonctionnalités SQL familières avec une infrastructure gérée.
Recommandations si vous connaissez déjà vos besoins
Si vous connaissez déjà bien vos besoins, voici nos recommandations de base :
Nous recommandons DynamoDB pour les applications sans serveur qui ont besoin de performances constantes à faible latence, d'un dimensionnement automatique et qui ne nécessitent pas de jointures ou de transactions complexes. Il est particulièrement bien adapté aux applications basées sur Lambda en raison de sa nature sans serveur.
Amazon RDS est un meilleur choix lorsque vous avez besoin de requêtes SQL complexes, de jointures ou lorsque vous avez des applications existantes utilisant des bases de données relationnelles. Sachez toutefois que la connexion des fonctions Lambda à Amazon RDS nécessite une configuration supplémentaire et peut avoir un impact sur les temps de démarrage à froid.
Éléments à prendre en compte lors de la sélection d'un service de base de données
Lorsque vous choisissez entre DynamoDB et Amazon RDS pour vos applications Lambda, tenez compte des facteurs suivants :
-
Gestion des connexions et démarrages à froid
-
Modèles d'accès aux données
-
Complexité des requêtes
-
Exigences relatives à la cohérence des données
-
Caractéristiques d'échelle
-
Modèle de coûts
En comprenant ces facteurs, vous pouvez sélectionner l'option qui répond le mieux aux besoins de votre cas d'utilisation particulier.
-
DynamoDB utilise une API HTTP pour toutes les opérations. Les fonctions Lambda peuvent effectuer des demandes immédiates sans maintenir les connexions, ce qui améliore les performances de démarrage à froid. Chaque demande est authentifiée à l'aide AWS d'informations d'identification sans surcoût de connexion.
-
Amazon RDS nécessite de gérer des pools de connexions car il utilise des connexions de base de données traditionnelles. Cela peut avoir un impact sur les démarrages à froid, car les nouvelles instances Lambda doivent établir des connexions. Vous devrez mettre en œuvre des stratégies de regroupement de connexions et éventuellement utiliser Amazon RDS Proxy pour gérer efficacement les connexions. Notez que l'utilisation d'Amazon RDS Proxy entraîne des coûts supplémentaires.
-
DynamoDB fonctionne mieux avec les modèles d'accès connus et les modèles à table unique. Il est idéal pour les applications Lambda qui ont besoin d'un accès constant à faible latence aux données basé sur des clés primaires ou des index secondaires.
-
Amazon RDS offre de la flexibilité pour les requêtes complexes et les modèles d'accès changeants. Il est mieux adapté lorsque vos fonctions Lambda doivent effectuer des requêtes uniques et personnalisées ou des jointures complexes sur plusieurs tables.
-
DynamoDB excelle dans les opérations simples basées sur des clés et dans les modèles d'accès prédéfinis. Les requêtes complexes doivent être conçues autour de structures d'index, et les jointures doivent être gérées dans le code de l'application.
-
Amazon RDS prend en charge les requêtes SQL complexes avec des jointures, des sous-requêtes et des agrégations. Cela peut simplifier votre code de fonction Lambda lorsque des opérations de données complexes sont nécessaires.
-
DynamoDB propose à la fois des options de cohérence finales et des options de cohérence fortes, avec une forte cohérence disponible pour les lectures d'un seul élément. Les transactions sont prises en charge, mais avec certaines limites.
-
Amazon RDS fournit une conformité totale en matière d'atomicité, de cohérence, d'isolation et de durabilité (ACID) ainsi qu'une prise en charge des transactions complexes. Si vos fonctions Lambda nécessitent des transactions complexes ou une forte cohérence entre plusieurs enregistrements, Amazon RDS peut être plus adapté.
-
DynamoDB s'adapte automatiquement à votre charge de travail. Il peut gérer les pics de trafic soudains provenant des fonctions Lambda sans pré-provisionnement. Vous pouvez utiliser le mode capacité à la demande pour ne payer que ce que vous utilisez, ce qui correspond parfaitement au modèle de mise à l'échelle de Lambda.
-
Amazon RDS dispose d'une capacité fixe en fonction de la taille d'instance que vous choisissez. Si plusieurs fonctions Lambda tentent de se connecter simultanément, vous risquez de dépasser votre quota de connexion. Vous devez gérer avec soin les pools de connexions et éventuellement implémenter une logique de nouvelle tentative.
-
La tarification de DynamoDB correspond parfaitement à celle des applications sans serveur. Avec une capacité à la demande, vous ne payez que pour les lectures et écritures réellement effectuées par vos fonctions Lambda. Le temps d'inactivité est gratuit.
-
Amazon RDS facture l'instance en cours d'exécution, quelle que soit son utilisation. Cela peut être moins rentable pour les charges de travail sporadiques qui peuvent être typiques des applications sans serveur. Toutefois, cela peut s'avérer plus économique pour les charges de travail à haut débit associées à une utilisation constante.
Mise en route avec le service de base de données que vous avez choisi
Maintenant que vous avez pris connaissance des critères de sélection entre DynamoDB et Amazon RDS et des principales différences entre eux, vous pouvez sélectionner l'option qui correspond le mieux à vos besoins et utiliser les ressources suivantes pour commencer à l'utiliser.
