Titre : Azure Cosmos DB — Vue d’ensemble complète : NoSQL, modélisation & premiers pas

Description :

Vous travaillez avec Azure et vous entendez parler de Cosmos DB partout, mais vous ne savez pas vraiment ce que c’est ni comment ça fonctionne ? Ce cours est fait pour vous.

Dans cette formation, on commence par les bases : pourquoi le NoSQL existe, quelles sont ses différences fondamentales avec une base SQL classique, et dans quels cas Cosmos DB est le bon choix. Pas de jargon inutile — on va droit au but avec des exemples concrets et visuels.

Vous apprendrez ensuite comment Cosmos DB est architecturé en interne : les containers, les partitions, la distribution mondiale, et pourquoi le choix de la partition key est l’une des décisions les plus importantes de votre conception.

On plonge ensuite dans la modélisation des données NoSQL, avec deux exemples complets et réalistes :

• Une application Pharmacie qui passe de 4 tables SQL à 1 seul document Cosmos DB
• Une application TechStore qui réduit 10 tables SQL à seulement 3 containers

Vous verrez aussi comment fonctionne l’API SQL de Cosmos DB — notamment la syntaxe FROM c qui déroute souvent les développeurs qui arrivent du monde relationnel.

On couvre également les fonctionnalités avancées : les Stored Procedures, les Triggers, les UDFs en JavaScript, ainsi que le Change Feed — un mécanisme puissant pour réagir en temps réel aux modifications de vos données.

Enfin, le cours se termine par un lab pratique dans le Data Explorer du portail Azure : vous créerez votre premier container, insérerez des documents JSON, et exécuterez vos premières requêtes SQL directement dans l’interface.

Ce cours s’adresse à :

• Les développeurs Azure qui veulent comprendre Cosmos DB sans se perdre dans la documentation officielle
• Les candidats qui préparent la certification AZ-204
• Toute personne qui vient du monde SQL et veut faire la transition vers le NoSQL sur Azure

Prérequis :

• Notions de base sur Azure (savoir naviguer dans le portail)
• Connaissance basique du SQL (SELECT, JOIN, WHERE)
• Aucune expérience préalable de Cosmos DB requise

À la fin de ce cours, vous aurez une vision claire et solide de Cosmos DB, vous saurez modéliser vos données pour le NoSQL, et vous serez capable de démarrer un projet réel sur Azure Cosmos DB en toute confiance.

Etude :

Guide de Transition : De SQL vers Azure Cosmos DB

Résumé Exécutif

Le passage d’une architecture SQL relationnelle vers une base de données NoSQL comme Azure Cosmos DB représente un changement fondamental de paradigme dans la gestion des données. Alors que le SQL repose sur une structure rigide de lignes et de colonnes, Cosmos DB utilise des documents JSON flexibles pour éliminer les contraintes liées aux valeurs nulles et aux schémas fixes.

Ce document détaille les concepts clés pour une transition réussie, notamment :

• La flexibilité du schéma : Le remplacement des tables SQL par des conteneurs sans schéma.
• L’architecture PaaS : La gestion automatisée par Microsoft de l’infrastructure, de la réplication et de la disponibilité (99,999 %).
• L’optimisation des performances : L’importance cruciale de la clé de partition et des Unités de Requête (RU) pour garantir l’évolutivité.
• La modélisation orientée document : L’abandon des jointures au profit de l’imbrication des données pour des lectures atomiques et rapides.

——————————————————————————–

1. Comprendre le Paradigme NoSQL et Azure Cosmos DB

Le NoSQL répond aux limites du SQL traditionnel, notamment le problème des colonnes vides (NULL) lorsque des entités de même type possèdent des attributs différents.

SQL vs NoSQL

• SQL (Rigide) : Chaque enregistrement doit respecter strictement les colonnes de la table. L’ajout d’un nouveau champ nécessite un ALTER TABLE.
• NoSQL (Flexible) : Les données sont stockées sous forme de documents JSON. Chaque document ne contient que les champs nécessaires. Aucun ALTER TABLE n’est requis pour ajouter de nouveaux types de données.

Azure Cosmos DB en tant que PaaS

Contrairement à SQL Server, qui peut être géré comme une infrastructure (IaaS), Cosmos DB est une Plateforme en tant que Service (PaaS). Microsoft gère l’intégralité de la pile :

• Mises à jour du matériel et du système d’exploitation.
• Sauvegardes automatiques toutes les 4 heures.
• Réplication mondiale et mise à l’échelle automatique.
• Disponibilité garantie à 99,999 %.

——————————————————————————–

2. Structure et Architecture de Données

Cosmos DB suit une hiérarchie stricte en quatre niveaux, comparable à l’environnement SQL :

Le Conteneur : Une table sans règles

Le conteneur est l’équivalent de la table SQL, mais sans structure fixe. Il stocke des documents JSON disparates. C’est également l’unité de mesure pour la performance : les ressources (RU/s) sont allouées au niveau du conteneur.

——————————————————————————–

3. Le Partitionnement : Clé de la Performance

Le partitionnement est le mécanisme par lequel Cosmos DB distribue les données sur plusieurs serveurs physiques pour assurer l’évolutivité.

Choisir une Clé de Partition

Le choix de la clé de partition est irréversible une fois le conteneur créé. Une bonne clé doit posséder :

• Une cardinalité élevée : Beaucoup de valeurs distinctes (ex: customerId).
• Une distribution uniforme : Les données doivent être réparties équitablement entre les serveurs.
• Un alignement avec les requêtes : La clé doit figurer dans les filtres des requêtes les plus fréquentes.

Coût et Efficacité des Requêtes

• Point Read (Lecture ponctuelle) : Recherche via id + partition key. Coûte exactement 1 RU. C’est l’opération la plus économique.
• Requête ciblée (In-partition) : Filtre incluant la clé de partition. Interroge un seul serveur.
• Requête croisée (Cross-partition) : Filtre sans clé de partition. Interroge tous les serveurs, ce qui est coûteux et inefficace.

——————————————————————————–

4. Modélisation et Relations : De la Jointure à l’Imbrication

En SQL, les relations sont gérées par le moteur de base de données via des clés étrangères et des jointures (JOIN). En Cosmos DB, les relations sont gérées par le code applicatif ou simplifiées par l’imbrication.

L’Imbrication des Données

Plutôt que de diviser les données en plusieurs tables (ex: Clients, Commandes, Lignes de commande), Cosmos DB préconise de regrouper les informations souvent lues ensemble dans un seul document JSON.

• SQL : 4 tables -> Jointures complexes -> Plusieurs lectures.
• Cosmos DB : 1 document -> 1 seule lecture -> Performance accrue.

L’API SQL (NoSQL)

Bien que Cosmos DB soit NoSQL, il utilise un langage de requête proche du SQL.

• FROM c : L’alias c représente le conteneur actuel. Comme Cosmos DB ne permet pas de jointures entre conteneurs, chaque requête ne cible qu’une seule source à la fois.
• Syntaxes identiques : SELECT, WHERE, ORDER BY, GROUP BY restent inchangés.
• Navigation : L’accès aux champs imbriqués se fait via la notation par points (ex: c.customer.name).

——————————————————————————–

5. Programmation Serveur et Flux de Données

Cosmos DB permet d’exécuter du code JavaScript directement côté serveur pour garantir l’atomicité ou automatiser des processus.

Le Change Feed (Flux de modification)

Le Change Feed est un journal ordonné de toutes les insertions et mises à jour. Il permet de réagir en temps réel aux modifications de données sans avoir à interroger la base de données en boucle (polling).

• Applications : Mise à jour de cache, notifications client (SMS/Email), alertes de stock faible, synchronisation avec d’autres systèmes via Azure Functions.

——————————————————————————–

6. Stratégies et Conseils de Migration

La migration d’un système SQL vers Cosmos DB ne doit pas être un simple copier-coller de données, mais une refonte structurelle.

Recommandations clés :

1. Redesign des données : Fusionner les tables SQL lues ensemble en un document unique.
2. Migration progressive : Commencer par les catalogues de produits ou profils utilisateurs. Conserver SQL pour les données nécessitant des transactions légales strictes (factures).
3. Stratégie de double écriture : Pendant la transition, écrire simultanément dans SQL et Cosmos DB. Basculer les lectures en premier, puis les écritures, et supprimer SQL après 30 jours sans incident.
4. Surveillance des RU : Surveiller les Unités de Requête dès le premier jour pour identifier les requêtes coûteuses.
5. Utilisation de l’Autoscale : Activer la mise à l’échelle automatique pour la production afin de gérer les variations de trafic de 10 % à 100 %.

Outils de Migration :

• Azure Database Migration Service : Analyse le schéma SQL et copie les données.
• Azure Data Factory : Pour les pipelines de transformation complexes.
• Cosmos DB Data Migration Tool : Outil en ligne de commande pour des copies simples.