Les fondamentaux du cloud computing
Bases de données dans le cloud
Ce qu'un service de base de données géré retire réellement de votre charge, comment les bases relationnelles et NoSQL modélisent les données différemment, et laquelle convient à quelle partie d'une application réelle.
- Expliquer ce qu'un service de base de données géré prend en charge par rapport à faire tourner une base soi-même
- Distinguer les bases de données relationnelles des bases NoSQL par leur modèle de données et leur profil de requête
- Choisir une base relationnelle ou NoSQL pour une charge donnée selon son profil d'accès
- Identifier les principaux produits de bases de données relationnelles et NoSQL gérées proposés par AWS, Azure et Google Cloud
Le problème des 2 heures du matin qu'une base gérée résout
Une base de données plante à 2 heures du matin. Quelqu'un doit s'en apercevoir, diagnostiquer s'il s'agit d'un mauvais correctif, d'une panne disque ou d'une requête devenue folle, et la remettre en route sans perdre de données. Faire tourner une base de données soi-même, même sur une machine virtuelle cloud, fait que ce quelqu'un, c'est vous. Un service de base de données géré existe pour que ce quelqu'un devienne le fournisseur à la place, pour tout sauf les parties auxquelles seul vous pouvez répondre, comme savoir quelles requêtes votre application fait réellement tourner.
Ce que "géré" prend réellement en charge
Amazon RDS est le modèle d'une base de données relationnelle gérée, et sa propre documentation est précise sur ce qui change de côté. Comparez faire tourner une base sur site, sur une simple instance EC2, et sur RDS :
| Tâche | Sur site | Sur EC2 | Sur RDS |
|---|---|---|---|
| Optimisation applicative | Vous | Vous | Vous |
| Mise à l'échelle | Vous | Vous | AWS |
| Haute disponibilité | Vous | Vous | AWS |
| Sauvegardes de la base | Vous | Vous | AWS |
| Installation des correctifs du logiciel | Vous | Vous | AWS |
| Installation des correctifs de l'OS | Vous | Vous | AWS |
| Maintenance du serveur | Vous | AWS | AWS |
Passer du sur site à EC2 confie le matériel physique. Passer d'EC2 à RDS confie presque tout le fonctionnement du moteur de base de données lui-même : correctifs, sauvegardes, mise à l'échelle, détection et récupération des pannes. Ce qui reste chez vous dans chaque colonne, c'est l'optimisation des requêtes, parce qu'elle dépend entièrement de votre application précise, de vos requêtes précises et de vos données précises, un travail qu'aucun service géré ne peut faire à votre place.
Bases relationnelles : des lignes qui se relient à d'autres lignes
Imaginez la table Commandes d'une boutique en ligne. Chaque ligne a besoin d'un client_id qui pointe vers une ligne réelle d'une table Clients séparée, et d'un product_id qui pointe vers une ligne de la table Inventaire. Cette relation imposée, une commande qui ne peut pas exister sans un client et un produit correspondants, est la caractéristique déterminante d'une base de données relationnelle : des données organisées en tables avec lignes et colonnes, interrogées avec SQL, et reliées entre tables par des clés. Amazon RDS prend en charge 6 moteurs sur ce modèle : MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle Database et IBM Db2, tous interrogeables avec le même modèle relationnel même si les moteurs sous-jacents diffèrent.
Cette structure est exactement ce dont une commande a besoin. Si un paiement échoue en cours de route, la base ne doit jamais laisser une commande pointer vers un client ou une ligne d'inventaire qui n'a plus de sens, et les bases relationnelles sont construites pour imposer ce type de cohérence.
Bases NoSQL : des recherches rapides sans les relations
Imaginez maintenant un classement pour un jeu avec 10 millions de joueurs simultanés, ou un panier d'achat lu et réécrit à chaque clic. Aucun des 2 n'a besoin d'être joint à une autre table, et aucun des 2 ne profite du coût d'imposer des relations entre tables. Les bases NoSQL, sur le modèle d'Amazon DynamoDB, abandonnent le modèle table-et-jointure au profit d'éléments récupérés directement par une clé, avec une structure flexible qui peut différer d'un élément à l'autre. DynamoDB annonce des performances de quelques millisecondes, que l'application serve des dizaines de milliers ou des centaines de millions d'utilisateurs simultanés, parce que toute la conception échange les relations entre éléments contre ce type d'échelle.
La frontière : faire correspondre le modèle au profil d'accès
| Propriété | Relationnel | NoSQL |
|---|---|---|
| Données organisées comme | Tables à lignes et colonnes fixes | Éléments indépendants, forme flexible |
| Relations entre enregistrements | Imposées par des clés et des jointures | Non intégrées, généralement évitées par conception |
| Langage de requête | SQL | API propres au produit, recherches par clé |
| Modèle de mise à l'échelle | Principalement verticale, avec des répliques de lecture | Horizontale par conception, construite pour un accès concurrent massif |
| Convient bien à | Des transactions qui doivent rester cohérentes entre enregistrements liés | Des charges à haute échelle et recherche simple, comme les sessions, paniers, classements |
| Produit AWS | RDS | DynamoDB |
| Produit Azure | Azure SQL Database | Azure Cosmos DB |
| Produit Google Cloud | Cloud SQL | Firestore |
Exemple chiffré : 1 plateforme, 2 bases de données
La même plateforme e-commerce de la leçon précédente a besoin des 2 modèles à la fois, pas d'un choix unique entre eux. Commandes, clients et inventaire vont dans une base relationnelle, parce qu'une commande qui référence un client ou une ligne d'inventaire inexistante est un bug, et le modèle relationnel est ce qui l'empêche. Le contenu du panier et les données de session vont dans une base NoSQL, parce que ces données changent en permanence, sont lues à presque chaque chargement de page, et n'ont jamais besoin d'être jointes à la table Commandes pour faire leur travail. Faire tourner les 2 côte à côte, plutôt que de forcer chaque type de donnée dans un seul modèle, est une architecture normale, pas un compromis.
Le piège : plus récent ne veut pas dire universellement meilleur
Il est tentant de traiter le NoSQL comme la mise à niveau moderne et le relationnel comme l'option héritée. Ce cadrage rate ce que chacun sacrifie réellement. Le NoSQL monte à une charge concurrente énorme précisément parce qu'il n'impose pas de relations entre éléments, exactement la garantie dont dépend un système de commandes et d'inventaire. Une application bien conçue ne choisit pas un camp une fois pour toutes, elle place chaque type de donnée dans le modèle construit pour son profil d'accès, c'est pourquoi les systèmes réels font souvent tourner relationnel et NoSQL côte à côte plutôt que de choisir l'un pour tout.
Où cela vous mène
Un service de base de données géré prend en charge les correctifs, les sauvegardes et la récupération des pannes pour que vous puissiez vous concentrer sur les requêtes et le schéma que vous seul comprenez. Choisissez une base relationnelle quand les enregistrements doivent rester cohérents entre tables, et choisissez le NoSQL quand la charge est une recherche simple à haut volume qui n'a pas besoin de ces relations. La prochaine leçon couvre comment le trafic atteint réellement ces bases de données et le calcul devant elles : le réseau cloud.