Azure Cosmos DB : NoSQL mondial

Azure Cosmos DB est le service de base de données NoSQL multimodèle et distribué à l’échelle mondiale de Microsoft. Il est conçu pour offrir une latence de lecture et d’écriture de quelques millisecondes, quelle que soit l’échelle et partout dans le monde. Contrairement aux bases de données traditionnelles limitées à une seule région, Cosmos DB peut répliquer de manière transparente les données dans des dizaines de régions Azure simultanément.

Cosmos DB prend en charge plusieurs API de bases de données au sein d’un même service. Vous pouvez utiliser l’API NoSQL native (documents JSON), l’API MongoDB pour les applications reposant sur des pilotes MongoDB, l’API Apache Cassandra pour les charges de travail en colonnes larges, l’API Gremlin pour les données de graphes et l’API Table pour les données clé-valeur. Chaque API expose le moteur sous-jacent de Cosmos DB au moyen d’une interface familière.

La hiérarchie des ressources Cosmos DB comporte trois niveaux. Un compte est la ressource de niveau supérieur qui définit la liste des régions de réplication et le niveau de cohérence. Dans un compte, vous créez des bases de données servant d’espaces de noms logiques. Dans chaque base de données, vous créez des conteneurs — l’unité qui contient les éléments (documents) et dans laquelle le débit est provisionné.

Une clé de partition est une propriété présente dans chaque élément, que Cosmos DB utilise pour distribuer les données entre les partitions physiques. Le choix de la clé de partition est essentiel : elle doit présenter une forte cardinalité (de nombreuses valeurs distinctes), répartir uniformément le trafic d’écriture et apparaître dans la majorité de vos requêtes. Un mauvais choix de clé de partition entraîne des partitions saturées qui limitent le débit et dégradent les performances.

Cosmos DB facture le débit en unités de requête par seconde (RU/s). Une RU correspond approximativement au coût de lecture d’un document de 1 KB par son ID. Les écritures, les requêtes et les suppressions consomment davantage de RU selon la taille de l’élément et la complexité de l’index. Vous pouvez provisionner les RU/s au niveau du conteneur ou partager un pool entre tous les conteneurs d’une base de données, et passer en mode autoscale pour laisser Cosmos DB ajuster automatiquement le débit.

La fonctionnalité la plus puissante de Cosmos DB est sa capacité à répliquer les données à l’échelle mondiale en quelques clics. Vous ajoutez des régions à votre compte, puis Cosmos DB synchronise automatiquement toutes les écritures dans chaque région. Chaque région peut servir simultanément les lectures et les écritures dans une configuration à écritures multiples (multi-maître), ce qui réduit la latence pour les utilisateurs géographiquement dispersés.

Cosmos DB propose cinq niveaux de cohérence réglables, classés du plus fort au plus faible : Strong (lectures linéarisables, latence la plus élevée), Bounded Staleness (les lectures accusent un retard limité sur les écritures), Session (valeur par défaut — lectures cohérentes pour vos propres écritures au sein d’une session), Consistent Prefix (les lectures n’observent jamais des écritures dans le désordre) et Eventual (lectures les plus rapides, garanties les plus faibles). Choisissez en fonction de la tolérance de votre application à l’utilisation de données obsolètes.

Par défaut, Cosmos DB indexe automatiquement chaque propriété de chaque élément que vous insérez, sans vous obliger à définir un schéma au préalable. Cela permet d’effectuer des requêtes ponctuelles flexibles sans maintenance des index. Vous pouvez personnaliser la stratégie d’indexation afin d’exclure les chemins qui ne sont jamais interrogés (pour réduire les coûts de stockage) ou d’ajouter des index composites pour les requêtes ORDER BY portant sur plusieurs propriétés.

Le flux de modifications est un journal trié de toutes les opérations de création et de mise à jour effectuées sur un conteneur Cosmos DB. Les applications s’abonnent au flux de modifications pour déclencher un traitement en aval — par exemple, mettre à jour un index de recherche, envoyer des notifications ou écrire dans une vue matérialisée. Le flux de modifications constitue la base des modèles pilotés par les événements et CQRS dans les architectures Cosmos DB.

Cosmos DB prend en charge Time-to-Live (TTL), une propriété que vous définissez sur un conteneur ou sur des éléments individuels pour les supprimer automatiquement après un nombre de secondes défini. Cette fonctionnalité convient parfaitement aux données de session, aux entrées de cache, aux journaux d’audit soumis à des périodes de conservation réglementaires ou à toute donnée dont l’expiration est connue. Les suppressions TTL sont effectuées comme des tâches en arrière-plan et ne consomment pas les RU/s provisionnées.

Cosmos DB propose deux modes de facturation. Le débit provisionné est facturé par RU/s-heure, quelle que soit l’utilisation réelle, et convient aux charges de travail stables et prévisibles. Le mode Serverless est facturé en fonction des RU consommées et des GB stockés, sans coût minimal, ce qui le rend économique pour le développement, le prototypage et les pics de trafic. Cosmos DB Serverless est actuellement limité à une seule région.

Testez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que Cosmos DB est un service NoSQL multimodèle distribué à l’échelle mondiale, que les clés de partition déterminent la manière dont les données sont réparties et doivent être choisies avec soin, et que cinq niveaux de cohérence vous permettent de trouver un équilibre entre latence et fraîcheur des données. Nous allons maintenant découvrir les services Azure gérés pour les moteurs de bases de données open source.