Développez des applications évolutives avec la bonne base de données : Azure Cosmos DB

Les technologies en cloud ont changé la vie quotidienne des développeurs ces dernières années et sont utilisées dans de plus en plus d'applications. Une technologie en cloud particulière de base de données que j'ai examinée de plus près ces dernières semaines est Azure Cosmos DB. Dans cet article, j'aimerais vous présenter les avantages de cette technologie et vous montrer pourquoi elle est particulièrement adaptée au développement d'applications web. Je vous expliquerai également son fonctionnement et vous montrerai comment configurer Cosmos DB.

Pourquoi Azure Cosmos DB est-il un bon choix pour le développement d'applications ?

Le service Azure fourni par Microsoft est hautement évolutif grâce à son architecture. Cela permet aux données d'être géographiquement proches de l'utilisateur et d'y accéder sans latence importante. Azure Cosmos DB est un service géré. Aucun serveur avec système d'exploitation ne doit être administré. Cela signifie que l'accent est mis sur le développement avec Cosmos DB et que l'administration traditionnelle est dépassée. De plus, la disponibilité garantie est de 99,999%, ce qui en fait une base de données idéale pour les applications conçues pour une haute disponibilité.

Qu'est-ce que Azure Cosmos DB et en quoi diffère-t-elle des autres bases de données ?

Dans la plupart des cas, Cosmos DB est utilisée avec l'API NoSQL. Par conséquent, les entités sont stockées sous forme de documents JSON et non pas sous forme de tableaux, comme c'est le cas avec SQL, par exemple. Cette approche offre une meilleure flexibilité dans le stockage des données sur des partitions, qui peuvent à leur tour être situées sur des serveurs différents. Le stockage d'entités sous forme de documents est sans schéma. En d'autres termes, il n'est pas possible, du côté de la base de données, de spécifier les propriétés qu'une entrée doit contenir. C'est particulièrement difficile à comprendre si vous avez déjà beaucoup travaillé avec des bases de données relationnelles et que vous êtes habitué à la structuration des données dans ce type d'environnement.

Les systèmes de bases de données relationnelles sont familiers avec l'option de spécifier si les colonnes doivent être indexées. En raison de l'absence de schéma décrite ci-dessus, cette option n'est pas disponible dans Cosmos DB. Pour s'assurer que les requêtes sont rapides, toutes les propriétés d'un document sont indexées. Fini le casse-tête des index primaires et secondaires.

Ces deux approches offrent un avantage majeur par rapport aux systèmes de base de données conventionnels : La flexibilité. Sans schéma, un objet peut être adapté ou étendu selon les besoins sans avoir à se soucier des migrations de base de données pour mettre le code et les tables de la base de données au même niveau. En outre, un mappeur OR n'est plus nécessaire puisque les objets sont stockés directement en tant que tels dans la base de données.

Quelles applications bénéficient d'Azure Cosmos DB ?

Le service de base de données de Microsoft basé sur le cloud est très polyvalent et peut donc être utilisé dans divers scénarios d'application. Qu'il s'agisse d'applications web, d'applications, de jeux, de logiciels IA ou IoT, la liste des utilisations est vaste. Les applications qui traitent beaucoup de données ou qui enregistrent de nombreux accès en lecture et en écriture au niveau mondial en profitent tout particulièrement. La mise à l'échelle verticale permet à la base de données d'évoluer avec vos besoins.

Comment une base de données Azure Cosmos DB est-elle mise en place et configurée ?

Comme de nombreux autres services Azure, Cosmos DB peut également être mis en place et configuré via le portail Azure ou le CLI Azure. Ce faisant, vous devez faire attention à quelques options, dont certaines ne peuvent plus être modifiées par la suite.

Sélection de l'API

La décision la plus importante lors de la création d'une instance Azure Cosmos DB est probablement le choix de l'API à utiliser. Le service offre plusieurs interfaces via lesquelles les données sont transférées et stockées.

• NoSQL: L'implémentation par Microsoft d'un système de base de données basé sur des documents. Les entités sont stockées sous la forme de documents JSON. Si vous souhaitez stocker des données sous la forme de documents JSON et que vous n'avez pas besoin d'une structure rigide, l'API NoSQL pourrait être le bon choix. Elle est particulièrement adaptée aux applications qui requièrent une certaine flexibilité dans la modélisation des données.
• MongoDB: Système de base de données open source pour les entités non relationnelles. Stocke les données au format BSON. Si vous avez déjà de l'expérience avec MongoDB ou si vous avez une application optimisée pour cette base de données, l'API MongoDB pourrait être le meilleur option pour vous.
• Apache Cassandra: Système open-source qui stocke les données dans ce que l'on appelle un "wide-column store". Si vous souhaitez principalement stocker de grandes quantités de données et y accéder rapidement, l'API Apache Cassandra pourrait vous convenir.
• Table: Un stockage clé-valeur développé par Microsoft. L'API Table est particulièrement adaptée aux applications conçues pour le stockage clé-valeur et nécessitant un accès rapide à ces données.
• Apache Gremlin: Base de données graphique open source. Basée sur Apache TinkerPop. Si vous souhaitez stocker et analyser des données sous forme de graphes, l'API Apache Gremlin est le bon outil.
• PostgreSQL: base de données relationnelle qui prend en charge les tables de base de données distribuées, les requêtes distribuées, etc. à l'aide de "Citus". Si vous avez déjà de l'expérience avec PostgreSQL ou si vous avez une application optimisée pour cette base de données, l'API PostgreSQL peut être le meilleur choix pour vous. Elle est particulièrement adaptée aux applications qui nécessitent des structures de données fixes et la possibilité d'utiliser des requêtes SQL.

Il n'existe pas de "meilleure API". La décision dépend de l'utilisation prévue et de la technologie utilisée jusqu'à présent.

Choix du mode de capacité

Lorsque vous créez une base de données Cosmos, vous avez le choix entre deux modes de capacité. Que vous optiez pour le débit provisionné ou le serverless a le plus grand impact sur la facturation. Chaque mode a ses avantages et ses inconvénients et il convient de décider au cas par cas quel mode convient à l'application concernée. Les critères suivants peuvent vous aider :

Critère	Serverless	Débit provisionné
Convient pour	Applications dont le comportement d'utilisation est imprévisible.	Applications à trafic constant et prévisible.
Comment ça marche	Aucune configuration n'est requise ; les requêtes de la base de données peuvent simplement être exécutées contre le conteneur.	Le débit provisionné sous forme d'unités de requête doit être défini à l'avance pour chaque conteneur.
Limite d'espace de stockage	50 Go (1 To à l'avenir)	Illimité
Paiement	Paiement à l'heure ; seules les RUs utilisées	Paiement à l'heure ; toutes les RUs qui ont été fournies à l'avance

Limiter les dépenses et faire des économies

Pour maîtriser les coûts, Microsoft propose deux options pour créer ce service Azure. Ces options ne sont disponibles qu'en mode de capacité "Provisioned throughput". Tout d'abord, Microsoft propose un "Free Tier Discount", qui peut être activé une fois pour un compte Azure Cosmos DB par abonnement. Les premiers 1000 RU/s et 25 GB de stockage sont gratuits.

Il existe également l'option "Limiter le débit total du compte". Elle est active par défaut et permet de contrôler les coûts en ne dépassant pas la limite de débit définie.

Distribution mondiale des données

Selon la région, différentes options peuvent être disponibles :

• Géo-redondance (uniquement pour le débit provisionné) : active la distribution mondiale des données en reliant deux régions entre elles (par exemple, l'Europe de l'Ouest avec l'Europe du Nord).
• Écritures multirégionales (uniquement pour le débit provisionné) : permet d'écrire dans la base de données à l'échelle mondiale.
• Zones de disponibilité: augmente la disponibilité de l'application en répartissant la base de données sur plusieurs centres de données dans la même région

Mise en réseau

Dans le secteur du réseau, les options de connexion doivent être aussi restreintes que possible. Cela signifie que l'accès à partir de tous les réseaux doit être évité et que les options d'accès doivent être définies à l'aide d'un pare-feu ou de points d'extrémité privés.

Stratégie de sauvegarde

Dans Azure Cosmos DB, vous pouvez choisir entre deux modes de sauvegarde :

• Continuous : sauvegarde continue des données dans chaque région du compte Cosmos DB, restauration possible de manière autonome via le portail Azure ou la CLI
• Périodique : sauvegarde périodique jusqu'à un mois, restauration par le service client

Chiffrage

Par défaut, les données sont cryptées à l'aide d'une clé gérée par le service. Cela signifie que les données stockées dans la base de données ne peuvent pas être lues sans cette clé. Cette protection peut être étendue en configurant une clé clé gérée par le client (CMK). Toutefois, l'utilisation d'une clé gérée par le client a une influence sur la consommation d'unités de requête.

Conclusion

Azure Cosmos DB aide à développer des applications évolutives et mondialement distribuées, car la technologie a été conçue précisément pour ce scénario. Cependant, les nombreuses options de configuration peuvent s'avérer écrasantes au début. Jusqu'à présent, j'ai utilisé Cosmos DB avec l'API SQL et je pense que l'approche consistant à stocker les entités sous forme de documents JSON est très pratique pour accéder aux données de manière programmatique. Dans ce scénario, vous n'avez plus besoin de mappeurs OR pour contrôler l'accès aux données et garder un œil sur les migrations de bases de données. Toutefois, vous devez veiller à pouvoir continuer à traiter les anciennes constellations lors du développement ultérieur des objets, car il n'y a pas de validation du schéma du côté de la base de données.