Les modèles de données et le choix de la bonne méthode de traitement des données

Choisir le bon modèle de données, ou comment opter pour la stratégie la plus pertinente en matière de gestion des données.

Les données ont toujours revêtu une grande importance pour les entreprises. Or, l’avènement du web a fait littéralement exploser leur volume – tout comme les méthodes permettant de les traiter – si bien que le rôle de la base de données en devient éminemment stratégique. S’ajoute à cela l’émergence, depuis quelques années, de nouvelles architectures de bases de données qui rendent leur choix encore plus complexe. Dès lors, sur quels éléments s’appuyer pour être sûr de faire le bon choix ?

Chaque système de base de données possède ses propres caractéristiques, qui reflètent la façon dont les concepteurs ont choisi d’appréhender les différentes problématiques liées à l’administration des données. Chacune de ces décisions découle de compromis dont l’objectif premier est de privilégier ce qui compte le plus. Par exemple, la cohérence des données doit-elle prévaloir sur la disponibilité de la base de données ? Faut-il favoriser l’évolutivité verticale d’une instance ou, au contraire, donner la priorité à l’évolutivité horizontale ?

Quel modèle de gestion des données choisir ?

Pour choisir le bon modèle, le plus simple est de s’atteler à déterminer la valeur ou l’importance des relations unissant les données de votre application. Une réflexion qui appelle d’autres questions :

- Combien de relations y a-t-il dans les données ?

- Quelle est la complexité de ces relations ? En d’autres termes, combien de types de relations y a-t-il ? Ces relations ont-elles des propriétés ou annotations ?

- À quelle fréquence l’application interroge-t-elle ces relations lors d’une requête utilisateur ?

En fonction de la réponse apportée à chacune de ces questions, vous pourrez juger de l’importance que les relations prendront au sein d’un jeu de données. Si vos données présentent une multitude de points de relation, leur valeur sera probablement plus élevée. Néanmoins, ces réponses peuvent être subjectives. En vous penchant sur la complexité de la relation – et sa valeur pécuniaire pour l’entreprise – il est possible de choisir avec plus de pertinence le modèle de gestion des données.

Alors, à quoi ces relations ressemblent-elles en pratique ?

- Un service de raccourcissement d’URL utiliserait un système de données pour faire le lien entre les adresses fournies par les utilisateurs et des séquences de caractères courtes et uniques. En d’autres termes, la seule relation qui existe en l’espèce est celle qui unit l’URL d’origine à la version raccourcie qui lui correspond. Un cas de figure dans lequel le modèle clé-valeur paraît tout indiqué.

- Une plateforme publicitaire aurait besoin d’extraire divers attributs d’une liste pour la gestion des sites web de son portefeuille. Eu égard aux exigences de flexibilité et à la faible quantité de lignes de cette structure, un modèle sous forme de tableau paraît idéal.

- Une application de gestion de contenus aurait besoin de stocker des métadonnées portant sur les différentes formes de supports. Pour les livres, cela engloberait des informations sur les chapitres et sections. En d’autres termes, on s’intéresse en l’espèce aux relations imbriquées d’un livre, une mission dont s’acquitterait parfaitement une base de données de type document.

- Une application ERP aurait besoin d’informations sur diverses entités commerciales, comme la gestion des stocks, les achats et les clients, ainsi que sur les relations qui les unissent. Dans ce scénario, le choix devrait se porter naturellement sur une base de données relationnelle.

- L’utilisation d’une application «client 360» suppose d’agréger au sein d’un seul et même fichier l’ensemble des informations clients issues des différents canaux qu’utilise une entreprise, de sorte à pouvoir les analyser dans leur contexte. Une tâche pour laquelle une base de données orientée graphes semble parfaitement adaptée.

Quel que soit le service ou l’application que vous mettez sur pied, vous parviendrez certainement à identifier le modèle de gestion des données le mieux adapté. Cependant, celui-ci devra être capable de tenir la distance. De même, il vous faudra accorder une vigilance accrue au type de relations que l’entreprise souhaite garder à l’œil ou exploiter pour générer de la valeur, celles-ci pouvant être amenées à changer.

Dès lors, la tentation première est de choisir un modèle plus expressif comme une base relationnelle ou orientée graphes, sans tenir compte des exigences fonctionnelles effectives de votre application. Or, la moindre erreur de casting en la matière peut coûter cher, tant en termes de frais d’assistance que de temps passé à migrer plus tard vers un autre modèle de données.

Un mauvais choix en matière de modèle de données peut aussi affecter le développement de logiciels et d’applications, en ce qu’il engendrerait des complications inutiles pour les développeurs. Mais la difficulté principale est due au surcroit de complexité du code requis pour la couche d’accès aux données.

En termes de coûts de maintenance logicielle, le choix du mauvais modèle peut venir alourdir la «dette technique» contractée pour que tout fonctionne comme il se doit et venir troubler le travail des développeurs, qui peuvent être contraints d’élaborer des solutions alternatives ou de programmer plus de code pour tout faire tourner. Au final, cela peut se traduire par des dépassementsde budget ou de délais – sans parler de la frustration générée ou du besoin de désigner des coupables.

À titre d’exemple, vous pourriez décider d’utiliser une base de données relationnelle pour intégrer toutes vos données clients dans une application «client 360». Bien que rien ne l’interdise au plan technique, cela impliquerait une longue réflexion sur la modélisation des données. Sans compter qu’il vous faudrait probablement développer davantage de code pour exécuter la moindre requête de recommandation, aussi simple soit-elle.

Avec une base de données de type graphe, la maintenance des questions commerciales peut se faire séparément de celle de l’application. On peut alors compiler un profil complet de chaque client dans lequel sont répertoriés ses derniers achats, les produits qu’il a visualisés, les recommandations qu’il a écrites, les mouvements effectués sur son panier et les articles qu’il a sauvegardés sur sa wish list. Ces données peuvent ensuite être exploitées pour dégager des tendances et déterminer qui achète quels produits. Une base de données orientée graphe sera donc plus facile à entretenir au fil du temps, mais aussi plus à même de générer de la valeur pour l’entreprise.

Toute médaille ayant son revers, le recours aux modèles de données plus complexes est à proscrire quand il n’est pas pleinement justifié. Si vous sauvegardez un ensemble d’historiques d’opérations dans une base de données orientée graphes, l’usage d’un langage de requête comme Gremlin sera malaisé et excessivement compliqué. Les bases de données plus simples offrent plus de lisibilité quant à leurs performances et occasionnent souvent de moindres frais. En outre, le mapping entre la modélisation logique des données et leur représentation physique au sein du système est plus clair.

Dans les modèles plus sophistiqués, comme les bases de données relationnelles ou orientées graphes, la bonne exécution des requêtes est souvent assurée par des optimisateurs de requêtes ainsi qu’une multitude de structures d’index. Cela provoque une multiplication des chemins d’accès aux données et des options de configuration tout en complexifiant l’exécution des requêtes. Si vous n’avez pas l’usage des capacités avancées de construction de relations qui font tout l’intérêt de ces modèles de données, vous allez payer ces fonctionnalités pour rien, tant en termes de performances que d’efforts de la part des professionnels chargés de leur déploiement.

Trouver la configuration la mieux adaptée à une application ou un service entier

Il est d’autant plus important de choisir le bon type de base de données pour votre application ou cas d’utilisation que toute erreur en la matière peut s’avérer extrêmement coûteuse. Toutefois, la plupart des applications créeront des données qui pourront être utilisées de diverses façons par l'entreprise. Cela peut conduire à des cas de figure dans lesquels il faut recourir à plusieurs modèles de données selon l’usage que l’on veut faire des données. Cela serait notamment le cas pour une application qui utiliserait des données issues d’appareils connectés puis les analyserait pour dégager des tendances et estimer leur valeur.

À la longue, le volume de données généré par les appareils connectés tend à prendre des proportions colossales, car ceux-ci renvoient des mises à jour aux serveurs centraux à intervalles réguliers. Aussi, si votre entreprise possède des milliers d’appareils qui actualisent leur statut tous les quarts d’heure, il vous faudra une solide base de données de séries chronologiques. Pour analyser ce jeu de données, il se peut toutefois que, selon la méthode choisie pour l’exploitation des données, vous ayez besoin en parallèle d’une autre configuration.

Les données entrantes seront-elles utilisées à des fins d’analyse «en temps réel» ou viendront-elles seulement enrichir un jeu de données plus étendu ? Y a-t-il, au sein du jeu de données, des relations que l’on peut voir à l’aide d’un modèle de données orienté graphe alors que les données de séries chronologiques devraient pour leur part être hébergées dans un emplacement distinct ?

En fonction de la valeur susceptible d’être générée en exploitant les données, il peut être nécessaire de faire appel à différents modèles de données pour un même service ou application. Cela suppose donc que les données soient déplacées ou transférées en tant que flux vers leur destination finale. Or, chaque modèle de données – et chaque plateforme de gestion des données qui l’accompagne – devra être pris en charge, à commencer par les systèmes de production.

Dans un futur proche, ce genre de bases de données «multimodèles» sera amené à revêtir davantage d’importance. Gartner prédit ainsi que «d’ici 2017, tous les grands systèmes de gestion de bases de données opérationnels intègreront plusieurs modèles de données, relationnels et NoSQL, au sein d’une même plateforme», selon une note de recherche de Nick Heudecker, Merv Adrian et Etisham Zaidi. L’objectif, en l’espèce, est de faciliter la prise en charge des systèmes de production, tout en choisissant toujours le modèle de données le plus adéquat pour l’application.

À l’avenir, il faudra d’emblée se pencher de près sur la valeur de chaque modèle de données. Tout mauvais choix en la matière peut alourdir inutilement les coûts et les frais de développement logiciel. Néanmoins, à mesure que les applications accroissent leur consommation de données et intègrent des déploiements de production dont l’architecture repose sur la valeur générée par les données, la nécessité de recourir à concomitamment à plusieurs modèles de données augmentera elle aussi. Les développeurs devront ainsi apprendre à envisager le traitement des données de diverses manières. Fort heureusement, ils pourront compter sur des outils de gestion des données multimodèles pour ce faire.