Bases de données sans serveur : une plongée profonde dans DynamoDB et Cosmos DB

La montée en puissance de l'informatique sans serveur a fondamentalement changé la façon dont les organisations construisent et déploient des applications. En abstractionnant la gestion du serveur, les développeurs peuvent se concentrer sur l'écriture de code et la livraison de fonctionnalités plutôt que sur la fourniture de matériel. Parmi les composants les plus critiques de ce paradigme, on peut citer les bases de données sans serveur, qui offrent une échelle de la demande, un prix à la carte et une disponibilité élevée sans frais généraux.

Quelles sont les bases de données sans serveur?

Les bases de données sans serveur sont des services de base de données qui gèrent automatiquement les tâches d'infrastructure telles que la fourniture, l'échelle, le patching et les sauvegardes. Le terme -serverless-less-les-serveurs ne signifie pas que les serveurs n'existent pas; plutôt, le fournisseur de cloud les gère entièrement, exposant seulement un paramètre de base de données à l'application.

Ce modèle est particulièrement avantageux pour les applications à trafic variable ou imprévisible, comme les ventes flash e-commerce, l'ingestion de capteurs IoT, les services de backend mobiles et les architectures basées sur des événements.Les bases de données sans serveur éliminent la planification de la capacité, réduisent les coûts inactifs et simplifient le développement en fournissant des API optimisées par latence et une réplication intégrée.

Amazon DynamoDB – Un pilier de l'AWS sans serveur

Amazon DynamoDB est une base de données de valeurs et de documents NoSQL entièrement gérée qui fournit des latences à millisecondes à un seul chiffre à toute échelle. Lancée en 2012, elle est devenue la base de données par défaut pour de nombreuses applications sans serveur AWS, fonctionnant en toute transparence avec Lambda, API Gateway, Step Functions et Kinesis. DynamoDB prend en charge les lectures cohérentes et fortement cohérentes, et offre des fonctionnalités telles que des tables globales, l'auto-échelle, la capacité à la demande, DynamoDB Streams pour la saisie de données et des indices secondaires mondiaux (IGS).

Caractéristiques clés de DynamoDB

  • Modèles de données flexibles:[ Prend en charge la valeur de la clé (clé primaire simple) et le document (clé primaire composite avec clé de tri). Les éléments peuvent avoir des attributs variables, ce qui facilite l'évolution sans migration de schéma.
  • Écaillage automatique:[ Vous pouvez choisir entre un débit fourni (avec évolutivité automatique) ou une capacité sur demande. Sur demande s'ajuste automatiquement pour les pics de trafic mais les frais par demande; fourni est plus rentable pour des charges de travail stables et prévisibles.
  • Tableaux mondiaux: Réplication multi-régions, multi-leaders avec consistance. Idéal pour la reprise après sinistre et les lectures/écritures à faible latence à travers le monde.
  • Accélérateur DynamoDB (DAX):[ Un cache en mémoire qui peut réduire la latence de lecture de millisecondes à un seul chiffre en microsecondes.
  • Sécurité:[ Chiffrement au repos (AWS KMS) et en transit (TLS), politiques de MAI à grain fin, paramètres de la VPC et intégration avec AWS CloudTrail pour les journaux d'audit.
  • Streams and Triggers: DynamoDB Streams capture les changements de niveau d'éléments en temps quasi réel, permettant des architectures animées par des événements (p. ex., réplique à Elasticsearch, mise à jour des index secondaires, déclenchement des fonctions Lambda).
  • Transactions: Opérations ACID sur une période allant jusqu'à 25 éléments ou 4 Mo de données, utiles pour les applications financières et les opérations multi-éléments.

Modèle de tarification

La tarification DynamoDB est basée sur le mode de capacité. La capacité prévue vous oblige à spécifier les unités de capacité de lecture et d'écriture (UCL/UCL). Vous payez un taux horaire par unité, plus les frais de stockage (0,25 $GB/mois). L'échelle automatique s'adapte à l'intérieur des limites que vous définissez. La capacité de demande frais par million d'unités de demande de lecture/d'écriture (UL/ULFR) et comprend une prime pour l'élasticité. Stockage, transfert de données, réplication des tables globales, DAX, Streams et sauvegarde sont facturés séparément. Pour les charges de travail spiky, à la demande peut être plus simple; pour les flux réguliers, provisionnés est généralement moins cher.

Cas d'utilisation courante

  • État de la session: Les lectures/écritures à faible latence le rendent excellent pour stocker les sessions des utilisateurs dans les applications web et mobiles.
  • Gaming: Profils de joueurs, classements et état de jeu avec une grande concordance et une charge imprévisible.
  • IoT: Ingestion de données de capteur avec échelle automatique pour gérer des millions d'écritures par seconde.
  • E‐commerce: Le traitement des commandes et des paniers d'achats par des transactions pour assurer l'uniformité.
  • Combiné avec Lambda et EventBridge, DynamoDB forme l'épine dorsale de nombreux moteurs sans serveur.

Limites et considérations

Bien que puissante, DynamoDB n'est pas une solution universelle. Ses capacités de requête sont limitées : vous ne pouvez que demander par clé primaire (ou GSI) et conditions de portée optionnelles. Les jointures complexes, l'agrégation et la recherche en texte intégral nécessitent des services externes comme Elasticsearch ou Aurora. La taille maximale de 400 KB peut être restrictive pour les documents de grande taille. Les tables globales se répliquent éventuellement (pas de cohérence forte entre les régions). La fourniture peut être difficile : une sous-estimation du débit conduit à un étranglement, tandis que la sur-fourniture gaspille de l'argent.

Amazon DynamoDB documentation officielle

Azure Cosmos DB – Base de données multimodèles distribuée à l'échelle mondiale

Microsoft Azure Cosmos DB est une base de données NoSQL entièrement gérée conçue pour les applications critiques pour la mission qui nécessitent une distribution globale, une échelle élastique et des modèles de cohérence multiples. Contrairement à DynamoDB, Cosmos DB est un modèle multi-modèle hors de la boîte : il prend en charge le document (API SQL), la valeur-clé (API de table), le graphique (API de Gremlin), la colonne-famille (API de Cassandra) et l'API de MongoDB. Cette flexibilité permet aux développeurs d'utiliser des langages de requête familiers tout en bénéficiant des garanties de réplication globale sous-jacentes Cosmos DB.

Caractéristiques clés de Cosmos DB

  • Vous pouvez choisir entre les API NoSQL (document), MongoDB, Cassandra, Gremlin (graphe) et Table. Toutes les API sont situées sur le même noyau — le moteur à DB Cosmos — et partagent donc le débit, l'indexation et la distribution globale.
  • Distribution mondiale (clé en main):[ En quelques clics ou lignes de code, vous pouvez reproduire des données dans n'importe quel nombre de régions d'Azure. Cosmos DB prend en charge les écritures multi-régions (actives) avec résolution automatique de conflits.
  • Cinq niveaux de cohérence bien définis:[ Fort, Tente, Session, Préfixe cohérent et Eventuel. Vous pouvez choisir le niveau par demande, en équilibrage des performances avec les garanties de cohérence.
  • Indication automatique:[ Par défaut, toutes les propriétés des éléments sont indexées sans définition manuelle de schéma. Ceci accélère les requêtes arbitraires, mais vous pouvez personnaliser les politiques d'indexation pour réduire la consommation de RU.
  • Unités de requête (RUs): Cosmos DB utilise une monnaie de débit unifiée mesurée en Unités de requête par seconde. 1 RU correspond à une lecture de 1 KB. Les lectures sont plus rapides (1 RU par lecture) que celles écrites (5 RU par 1 KB écrire). Vous fournissez un débit par conteneur ou base de données, ou utilisez le mode sans serveur (autoscale).
  • SLA garantit : 99,99 % de lecture disponible, 99,99 % écrit pour plusieurs régions et <10 ms de latence pour lire et écrire à P99 (dans la même région).
  • Modifier le flux:[ Un journal de modifications d'articles, commandé et persistant, qui peut être consommé par les fonctions Azure ou d'autres processeurs pour les architectures animées par des événements.
  • Store analytique:Store colonnelaire intégré pour l'exécution de requêtes analytiques à grande échelle sans impact sur les charges de travail transactionnelles (en utilisant Synapse Link).

Modèle de tarification

Vous pouvez également utiliser le mode serverless (prévisualiser au moment de l'écriture) où vous payez pour les RU et le stockage consommés, à l'échelle zéro lorsque vous êtes inactif — idéal pour les petites charges de travail. Le débit fourni peut être réglé par conteneur ou par base de données. Autoscale vous permet de fixer une limite maximale de RU et le système s'adapte dans cette plage. Le stockage coûte environ 0,25 Go/mois (similaire à DynamoDB). Les coûts de transfert de données pour la réplication multi-régions sont supplémentaires. Cosmos DB fournit un niveau gratuit de 1000 RU/s et 25 Go de stockage pour le premier compte par abonnement.

Par rapport à DynamoDB, la modélisation de l'ETC Cosmos DB-S est plus granulaire et peut être plus complexe à estimer, surtout pour les charges de travail multimodèles. Cependant, l'indexation automatique et la cohérence thonière peuvent réduire les ETC totaux nécessaires, surtout pour les applications lue-lourdes qui peuvent tolérer une éventuelle cohérence.

Cas d'utilisation courante

  • Applications SaaS d'entreprise:[ Systèmes multi-locataires qui nécessitent un accès géo-distribué à faible latence et des SLA solides.
  • IoT et séries chronologiques: ingérant des données de capteur à haute vitesse avec des vues globales.
  • Plateaux de commerce électronique: Catalogues de produits, paniers d'achat, gestion des commandes, avec déploiements actifs multi-régions.
  • Analyse en temps réel:[ Utilisation de flux de changement et Synapse Link pour conduire des tableaux de bord et des modèles d'apprentissage automatique.
  • Applications graphiques:[ Réseaux sociaux, moteurs de recommandation et graphiques de connaissances via l'API Gremlin.

Limites et considérations

L'ampleur de Cosmos DB= est fournie avec une courbe d'apprentissage. Le modèle RU nécessite une planification minutieuse : vous payez pour la capacité allouée même en cas de panne (sauf si vous utilisez sans serveur). L'efficacité des requêtes arbitraires repose souvent sur l'indexation automatique, mais des index mal conçus peuvent exploser le coût de RU. Les requêtes entre partitions sont moins efficaces car elles touchent chaque partition. Des lectures très cohérentes et des écritures multi-régions augmentent la latence et les coûts. Le magasin analytique n'est disponible que pour l'API SQL et l'API MongoDB. Cosmos DB est lié à l'écosystème Azure; l'intégration avec d'autres nuages ou sur-locaux peut être plus complexe. La taille limite des articles est de 2 Mo (vers. DynamoDB= 400 KB).

Document officiel de la Banque de développement de l'Azure Cosmos

Comparaison entre les têtes : DynamoDB et Cosmos DB

Le choix entre ces deux bases de données sans serveur dépend de votre fournisseur de cloud existant, des caractéristiques de la charge de travail et des exigences spécifiques de fonctionnalités.

Modèle de données et API

DynamoDB est principalement une valeur clé et un document. Il utilise une API propriétaire (AWS SDK) avec PartiQL (langage de requête compatible SQL): Cosmos DB offre cinq API: SQL (document), MongoDB, Cassandra, Gremlin (graphe), et Table. Cela donne un avantage clair à Cosmos DB pour les équipes qui souhaitent utiliser des pilotes existants ou migrer à partir d'autres bases de données NoSQL sans réécrire des requêtes.

Répartition mondiale

DynamoDB utilise des tables mondiales avec une cohérence éventuelle (ou une force unique dans une seule région). Cosmos DB fournit des écritures multi-régions avec des niveaux de cohérence multiples, y compris des niveaux forts entre les régions (bien que avec le coût de la latence).

Modèles de cohérence

DynamoDB offre deux options : ultime et forte. Cosmos DB en offre cinq : éventuel, préfixe cohérent, session, inertie limitée et forte. La granularité plus fine permet à Cosmos DB d'optimiser les coûts et les performances pour des cas d'utilisation spécifiques (p. ex., la cohérence de niveau de session pour les paniers de commerce électronique est très populaire).

Interrogation et indexation

DynamoDB vous demande de définir une clé primaire et une clé de tri optionnelle ; elle indexe automatiquement les clés primaires et les GSI. Vous pouvez également créer des index clairs. La requête ad-hoc est limitée. Cosmos DB indexe automatiquement toutes les propriétés par défaut, permettant des requêtes arbitraires sans définition de schéma initial. Cela rend Cosmos DB plus flexible pour les requêtes exploratoires, mais peut augmenter le coût RU pour les charges de travail à écriture élevée.

Production et tarification Granularité

DynamoDB utilise RCU/WCU – lire est la moitié du coût d'écriture (1 RCU pour 4 KB, 1 WCU pour 1 KB). Cosmos DB utilise RUs – 1 RU = 1 KB lire, 5 RU par 1 KB écrire. Cosmos DB=1 Le coût d'RU varie selon le niveau de cohérence et les propriétés indexées. DynamoDB=1 est les frais sur demande par unité de demande, tandis que Cosmos DB=1 est les frais sans serveur (prévisualiser) par RU consommé.

Intégration des écosystèmes

DynamoDB est profondément intégrée à AWS (Lambda, API Gateway, Kinesis, CloudWatch, CloudTrail, IAM). Cosmos DB s'intègre naturellement à Azure (fonctions, applications logiques, Event Hubs, Synapse, Power BI). Les deux offrent des flux de changement et des déclencheurs animés par des événements. Le choix revient souvent au fournisseur de cloud dans lequel votre organisation est investie.

Limitations et AMP

Cosmos DB propose des SLA complets pour la latence (P99 < 10 ms read/writes under 1 KB), le débit (haute disponibilité) et la consistance (forte). DynamoDB annonce une latence à un chiffre milliseconde et une disponibilité à 99,999% pour les tables globales, mais n'offre pas de SLA de latence formelle. Cosmos DB dispose également d'un stockage maximum par conteneur de 20 TB (ou illimité avec partition fractionnement), tandis que DynamoDB dispose d'une limite de taille d'article de 400 KB et de 10 Go par partition dure (bien que vous puissiez échafauder des partitions).

Quand choisir lequel ?

  • Choisissez DynamoDB si: Vous construisez sur AWS, avez besoin d'un simple magasin de valeurs clés ou de documents avec une faible latence prévisible, ont un modèle d'accès clair (requête principalement par clé primaire), et veulent garder les coûts bas à grande échelle.
  • Choisissez Cosmos DB si: Vous avez besoin d'un support multimodèle (surtout l'API MongoDB ou Cassandra pour la migration), vous avez besoin de niveaux de cohérence multiples, vous avez besoin d'écritures actives dans plusieurs régions ou vous avez besoin de fonctionnalités de requêtes riches sans conception d'index initial.

Guide du développeur DynamoDB -]Cosmos DB Introduction

Meilleures pratiques pour l'adoption de bases de données sans serveur

Quelle que soit la base de données que vous choisissez, suivre des modèles éprouvés vous aidera à éviter les pièges communs:

Conception pour la partitionnement

Dans DynamoDB et Cosmos DB, la conception de la clé de partition est critique. Les partitions chaudes (où une seule clé reçoit un débit disproportionné de trafic) permettent de faire des gaz. Utilisez des touches de haute cardinalité (p. ex. ID utilisateur, ID périphérique) et envisagez d'écrire des sharding pour les identifiants séquentiels.

Capturer les données de changement de levier

DynamoDB Streams et Cosmos DB Change Feed permettent des modèles animés par des événements. Utilisez-les pour reproduire des données aux moteurs de recherche (Elasticsearch), construire des vues matérialisées, synchroniser avec les entrepôts de données ou déclencher des processus en aval.

Comprendre vos besoins de cohérence

Si cela est acceptable, vous pouvez réduire les coûts et améliorer la latence. Pour Cosmos DB, utilisez la cohérence de session pour de nombreuses applications de e-commerce ou de médias sociaux – elle fournit des garanties de lecture-votre-écriture par session client à un coût RU inférieur à fort.

Utiliser le mode Capacité appropriée

Pour DynamoDB, choisissez une capacité fournie avec auto-échelle pour des charges de travail stables et sur demande pour des pics imprévisibles. Pour Cosmos DB, le débit fourni avec auto-échelle est bon pour la plupart des charges de production; considérez sans serveur (preview) pour les applications dev/test ou légères. Surveillez les RU consommés et définissez des alertes pour les événements de gaz.

Plan de secours et de relèvement après sinistre

Les deux services offrent une récupération ponctuelle (PITR). Activez-la pour toutes les bases de données de production. La sauvegarde DynamoDB est continue et restaure une nouvelle table; la sauvegarde Cosmos DB peut être continue ou périodique. Test restaure périodiquement. Pour la DR globale, configurez la réplication multi-régions (Global Tables ou Cosmos DB multi-region écrit) et avez un plan de basculement.

Gestion des coûts

Pour DynamoDB, utilisez une capacité réservée pour un débit prévisible. Pour Cosmos DB, envisagez d'utiliser sans serveur ou auto-échelle pour éviter de payer pour les RU au ralenti. Enlever les index et les tables inutilisés. Utilisez la compression lorsqu'elle est prise en charge (p. ex., en permettant la compression dans le magasin analytique Cosmos DB=).

Conclusion

DynamoDB excelle dans la simplicité, les motifs de requête étroits et l'intégration profonde de l'AWS, ce qui en fait un choix par défaut pour de nombreux microservices sans serveur. Cosmos DB offre une flexibilité supérieure avec un support multimodèle, une cohérence et des SLA complets, répondant aux besoins complexes d'applications mondiales et de polyglottes. Le bon choix dépend en fin de compte de votre stratégie cloud, des modèles d'accès aux données et de la tolérance pour la complexité opérationnelle.

AWS Serverless Database Resource Hub )?Page de produit DB de l'Azure Cosmos