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électionner 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 base de données AWS sont compatibles avec Lambda, mais ils ne sont pas nécessairement tous adaptés à votre cas d’utilisation particulier.
Quelles sont les options proposées lors de la sélection d’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 offre une mise à l’échelle transparente et des performances constantes de l’ordre de quelques millisecondes à n’importe quelle é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, dont MySQL et PostgreSQL. Il fournit les fonctionnalités familières de SQL 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 et d’une mise à l’échelle automatique, et qui ne nécessitent pas de jointures ou de transactions complexes. Cette solution est particulièrement adaptée 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 si 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 de cohérence des données
-
Caractéristiques de mise à l’échelle
-
Modèle de coût
La compréhension de ces facteurs vous permettra de choisir l’option qui répond le mieux aux besoins de votre cas d’utilisation.
-
DynamoDB utilise une API HTTP pour toutes les opérations. Les fonctions Lambda peuvent effectuer des requêtes immédiatement sans maintenir de connexion, 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 groupes de connexions, car il utilise des connexions de base de données traditionnelles. Cela peut affecter 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 le Proxy Amazon RDS pour gérer efficacement les connexions. Notez que l’utilisation du Proxy Amazon RDS 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 sur la base de clés primaires ou d’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 les 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 le code de votre fonction Lambda lorsque des opérations de données complexes sont nécessaires.
-
DynamoDB propose à la fois des options de cohérence finale et de cohérence forte, la cohérence forte étant disponible pour les lectures d’un seul élément. Les transactions sont prises en charge, mais avec certaines restrictions.
-
Amazon RDS offre une conformité totale en matière d’atomicité, de cohérence, d’isolation et de durabilité (ACID) et une prise en charge des transactions complexes. Si vos fonctions Lambda nécessitent des transactions complexes ou une cohérence forte entre plusieurs enregistrements, Amazon RDS pourrait ê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é-approvisionnement. Vous pouvez utiliser le mode de 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 connexions. Vous devez gérer avec soin les groupes de connexions et éventuellement implémenter une logique de nouvelle tentative.
-
La tarification de DynamoDB est parfaitement adaptée aux applications sans serveur. Avec une capacité à la demande, vous ne payez que pour les lectures et écritures réellement utilisées par vos fonctions Lambda. Le temps d’inactivité n’est pas facturé.
-
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 sont courantes dans les applications sans serveur. Toutefois, cela peut s’avérer plus économique pour les charges de travail à haut débit avec une utilisation constante.
Commencer 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 les deux, vous pouvez sélectionner l’option qui répond le mieux à vos besoins et utiliser les ressources suivantes pour commencer à l’utiliser.
