Les développeurs de logiciels ont aujourd’hui plus d’options qui s’offrent à eux. Ils disposent d’outils et de services qui peuvent les aider à créer rapidement de nouvelles applications, puis à lancer ces services auprès de clients dans le monde entier, puis à les faire évoluer pour répondre à la demande croissante. Les architectures de microservices et le développement agile mettent l’accent sur une évolution plus rapide et sur la création de nouveaux services chaque fois que les besoins des clients et les besoins de l’entreprise doivent être satisfaits.
Cela s’applique également aux données. Les développeurs doivent prendre en charge les données créées par leurs applications, ce qui signifie implémenter une base de données. Choisir le bon design peut faire toute la différence pour l’application ; Cela permet de garantir que l’application sera disponible, performante et évolutive dans le temps. Cependant, les développeurs ne veulent pas avoir à implémenter et à gérer eux-mêmes les bases de données. C’est pourquoi la majorité des entreprises (90 %, selon IDC) sont en train de migrer leurs bases de données et leurs charges de travail de données vers le cloud.
Pour ces entreprises, plusieurs options différentes sont disponibles. Il s’agit notamment des services gérés, des installations de bases de données basées sur le cloud et des offres de base de données en tant que service (DBaaS). Ces services promettent tous d’alléger le fardeau de la gestion des données et d’aider les développeurs à atteindre leurs objectifs de livraison plus rapide de nouvelles applications et de mises à jour d’applications. Des expressions comme « sans schéma » et « entièrement géré » peuvent donner l’impression que les bases de données peuvent être transférées, berçant les développeurs dans un sentiment de complaisance.
En réalité, les développeurs sont tout aussi responsables de l’infrastructure cloud que des systèmes traditionnels sur site, en particulier en ce qui concerne les choix de conception et la manière de mettre en œuvre la base de données. Il ne s’agit pas simplement de croire que les paramètres par défaut des produits DBaaS conviennent à leurs applications.
Choisir la bonne base de données
Les développeurs et les architectes d’applications doivent donc envisager l’avenir à long terme de leurs projets d’application et s’assurer qu’ils comprennent les exigences de base que ces projets auront. La première question est de savoir quelle conception de base de données utiliser pour le projet.
Il y a tellement d’options de base de données disponibles aujourd’hui que les choix deviennent rapidement écrasants. Le classement DB-Engines répertorie 359 bases de données différentes, par exemple, il y a donc beaucoup de tentation d’utiliser une base de données que vous connaissez déjà, ou une qui fait de grandes promesses sur ce qu’elle offrira. Si vous avez implémenté MongoDB, par exemple, pourquoi ne pas utiliser cette même base de données pour votre prochain projet ?
Cependant, rien ne garantit que ce qui a fonctionné pour une application fonctionnera pour une autre. Certaines bases de données et approches de gestion des données sont plus adaptées à des cas d’utilisation spécifiques, tels que les bases de données de graphes et de séries chronologiques, et d’autres peuvent être mieux adaptées en fonction du langage de programmation ou des ressources de développement logiciel qui seront utilisées. Bien qu’il soit possible de forcer un déploiement de base de données inadapté à un cas d’utilisation, un mauvais choix peut sérieusement réduire les performances et augmenter les coûts.
Pour choisir la bonne base de données, il faut comprendre comment une charge de travail d’application se comportera au fil du temps, comment elle se développera et comment les modèles d’accès pourraient changer. À mesure que toute implémentation de base de données se développe, elle devra gérer plus de requêtes et plus de données stockées. Mettre en place la bonne approche dès le départ peut faciliter le traitement d’un plus grand nombre de requêtes sur ces données. Ignorer cela et compter sur le service de base de données pour le gérer en votre nom peut fonctionner correctement au début, mais cela peut affecter les performances et les coûts par la suite. Consacrer du temps à la planification en amont peut donc entraîner des réductions de coûts significatives à plus long terme.
Comment penser à la conception de la base de données
Adopter une approche sans schéma séduit de nombreux développeurs. Après tout, si vous laissez le service de base de données s’occuper d’organiser les données, vous n’avez pas à le faire. Cependant, ce n’est pas vraiment le cas. Tous les fournisseurs de bases de données, même ceux qui proposent des approches « sans schéma » utilisant JSON ou la possibilité d’ajouter des objets, encouragent une certaine forme de validation de schéma. Les bases de données sans schéma stockent les informations sous forme de données non structurées, ce qui a un impact significatif en termes de performances et de coût à mesure que la mise en œuvre se développe.
Même les plus petites décisions peuvent avoir un impact important à mesure que les bases de données évoluent. Prenez les formats de données, par exemple. Imaginez que vous ayez un formulaire dans votre application qui acceptera des entrées de données, telles que le pays dans lequel vit une personne. Quel format devez-vous utiliser ?
Les noms de pays varient en longueur, supposons donc une moyenne de 12 caractères pour l’entrée. Stocker ces données dans un caractère variable (varchar) avec un jeu de caractères UTF occupera trois octets par caractère, soit 39 octets au total pour chaque entrée. Cela ne semble pas énorme, mais comparons cela avec l’utilisation int ou enum pour ce même champ : Un int ne nécessite que quatre octets au total pour chaque entrée, tandis qu’un enum ne prend qu’un octet. Augmentez cela jusqu’à 100 millions de points de données, et le varchar l’option prendrait 3700 mégaoctets (Mo) d’espace, tandis que l’option enum l’option nécessiterait 95 Mo, soit une réduction de 97,5 %.
La quantité de données que vous stockez a un impact plus important que l’augmentation de l’espace disque que vous utilisez. Lorsque vous avez plus de données avec lesquelles travailler, vous augmentez normalement l’image de la machine que vous utilisez pour traiter ces données en mémoire. Si vous adoptez une approche moins efficace des données, vous devrez augmenter les ressources CPU et mémoire pour traiter les données. Bien que le coût de stockage de téraoctets de données sur disque soit relativement bon marché, le coût du processeur et du temps de calcul est élevé, vous devez donc essayer d’adopter l’approche la plus efficace possible.
Parallèlement à cela, il est important de prendre en compte les modèles d’accès aux données. La façon dont vous prévoyez de rechercher des données affectera la façon dont vous concevez votre base de données. Si vous prévoyez d’avoir des requêtes de recherche courantes pour votre application, vous pouvez créer des index susceptibles d’améliorer les performances. De même, vous pouvez constater que le comportement de vos utilisateurs change au fil du temps et que certaines requêtes deviennent plus populaires. Pour gérer cela, vous devez revoir ces modèles car les requêtes et les index que vous avez en place ne seront plus ce dont vous aurez besoin à l’avenir.
Un élément important ici est que la conception de la base de données est potentiellement difficile à réfléchir. Cependant, vous pouvez vous faciliter la tâche si vous gardez votre déploiement aussi simple que possible plutôt que d’essayer de répondre aux cas extrêmes potentiels ou aux exigences futures. Il est toujours possible d’étendre votre schéma de base de données ou d’étendre votre déploiement à l’avenir, plutôt que de se concentrer sur les besoins futurs dès maintenant.
Réfléchir avant de construire
Ce que vous décidez avant de commencer à coder aura le plus grand impact sur votre évolutivité et votre stabilité, par rapport à toute décision que vous prendrez pendant la durée de vie d’un projet. Il est donc important d’accorder à vos données, et à ce que vous choisissez d’utiliser pour gérer ces données, le respect qu’elles méritent.
Plutôt que de confier toute la responsabilité à un service cloud ou à un fournisseur tiers, comprenez ce que vous voulez réaliser et la meilleure façon d’atteindre cet objectif. Cependant, vous ne renoncez pas à la responsabilité de cette décision en choisissant un service, et vous échangez la flexibilité contre les performances et les coûts. Le simple fait d’ajouter plus de ressources cloud n’est pas une approche efficace pour passer à l’échelle. Les choix de base de données et de conception que vous choisissez auront un impact sur le succès de votre nouvelle application ou service au fil du temps.
Matt Yonkovit est responsable de la stratégie open source chez Percona.
—
Le New Tech Forum offre un lieu d’exploration approfondie et étendue des technologies d’entreprise émergentes. La sélection est subjective, basée sur notre sélection des technologies que nous pensons importantes et les plus intéressantes pour les lecteurs d’InfoWorld. InfoWorld n’accepte pas les supports marketing pour publication et se réserve le droit de modifier tout le contenu contribué. Envoyez toutes les demandes à newtechforum@infoworld.com.
Copyright © 2022 IDG Communications, Inc.