Bien choisir son type de base de données

Les différents types de systèmes de gestion de base de données existant sur le marché ont chacun leurs forces et leurs faiblesses. Encore faut-il bien les connaître pour bien choisir.

Le système de gestion de base de données (SGBD) est aujourd’hui au cœur des systèmes opérationnels et analytiques. En effet, si les données constituent l’élément vital de l’entreprise, le SGBD est l’organe qui permet de les stocker, de les administrer, de les sécuriser et de les mettre à la disposition des applications et des utilisateurs.
Il existe cependant de nombreux types de SGBD sur le marché, offrant chacun leurs propres avantages et inconvénients. 

Les bases de données relationnelles, ou SGBDR sont devenues la norme en informatique il y a plus de 30 ans, avec l’apparition de serveurs économiques et assez puissants pour rendre ces produits largement utilisables et relativement abordables. Mais certains inconvénients se sont fait jour lors de l’avènement du Web et de l’informatisation intégrale de l’entreprise, mais aussi, de plus en plus, de la vie quotidienne.

Aujourd’hui, les services informatiques cherchent à traiter des données non structurées ainsi que des ensembles de données de structure très variable. Aussi auront-ils sans doute tout intérêt à se tourner vers les technologies NoSQL.

Par ailleurs, les applications qui exigent des transactions à grande vitesse et des taux de réponse rapides, ou bien qui soumettent les données à des analyses complexes en temps réel ou quasi réel, tireront quant à elles parti des bases de données en mémoire (In Memory).

Enfin, certains services informatiques pourront envisager de combiner plusieurs technologies de base de données pour des traitements particuliers.

Le paysage actuel des bases de données se révèle souvent complexe et déroutant. Aussi est-il important de comprendre les types et catégories de SGBD, et de savoir quand et pourquoi les utiliser. Le présent document vous servira de guide.

Catégories et modèles de SGBD

Il y a peu de temps encore, le SGBDR était la seule catégorie digne d’intérêt. Mais la vague du Big Data a apporté son lot de nouveaux types de produits fiables, aptes à concurrencer les logiciels relationnels dans certains scénarios d’utilisation. De plus, tous les types de SGBD se voient adjoindre de nouvelles technologies et fonctions, ce qui complique encore l’offre proposée.

Le SGBDR

Quoi qu’il en soit, le leader incontesté en termes de recettes et de base installée reste le SGBDR. Reposant sur la théorie mathématique des ensembles, les bases de données relationnelles offrent à la plupart des applications, qu’elles soient opérationnelles ou analytiques, des performances suffisantes en matière de stockage, d’accès et de protection. Pendant plus de trois décennies, les principaux SGBD opérationnels étaient de type relationnel, et produits par des géants du secteur : Oracle, Microsoft (SQL Server) et IBM (DB2).

Fiable, le SGBDR s’adapte à la plupart des scénarios d’utilisation ; sa position est renforcée par des années d’utilisation au sein des entreprises du classement Fortune 500 (ainsi que d’autres, plus modestes). Bien entendu, une telle stabilité a un coût : un SGBDR n’est pas donné.

Par ailleurs, la prise en charge de l’atomicité, de la cohérence, de l’isolation et de la durabilité des transactions (propriétés regroupées sous l’acronyme ACID) est une fonction incontournable du SGBDR. Ces propriétés garantissent l’exécution correcte de toutes les transactions ou, en cas d’échec de celles-ci, le retour d’une base de données à son état antérieur.

Alors, sachant la robustesse du SGBDR, on est en droit de se demander pourquoi les autres types de systèmes de base de données gagnent en popularité.

Il semblerait que le traitement des données à l’échelle du Web et les exigences du Big Data viennent remettre en question les capacités du SGBDR. Bien qu’il soit possible d’utiliser des SGBDR dans ces domaines, dans un environnement dynamique, en pleine évolution, les offres de SGBD qui proposent des schémas plus souples, des modèles de cohérence moins rigides et une gestion induite du traitement, moins importante, peuvent s’avérer avantageuses. C’est là qu’intervient le SGBD NoSQL.

Le SGBD NoSQL

Alors que le SGBDR exige un schéma strictement défini, une base de données NoSQL autorise un schéma flexible, dans lequel il n’est pas nécessaire de définir chaque donnée pour chaque entité. Ainsi, pour les structures de données définies de façon moins précise et susceptibles d’évoluer dans le temps, un SGBD NoSQL peut représenter une solution plus pratique.

Une autre différence entre les deux modèles réside dans leur façon d’assurer la cohérence des données. Le SGBDR peut garantir une cohérence systématique des données. Les SGBD NoSQL, en revanche, offrent généralement une approche plus souple, tendant vers une cohérence finale (bien que certains fournissent divers modèles de cohérence compatibles avec une prise en charge ACID intégrale).

Pour être honnête, la plupart des SGBDR proposent aussi, à différents degrés, des fonctions de verrouillage, de cohérence et d’isolation qui peuvent servir à mettre en œuvre la cohérence finale ; là où de nombreux SGBD NoSQL ajouteront des options pour une totale compatibilité avec les propriétés ACID.

Par conséquent, le NoSQL répond à certains des problèmes rencontrés par les technologies des SGBDR, facilitant ainsi la manipulation de grandes quantités de données éparses. On considère les données comme éparses lorsqu’elles ne sont pas toutes renseignées, et lorsque les valeurs proprement dites sont séparées par d’importants « espaces vides ». Pensez par exemple à une matrice contenant de nombreux zéros, mais peu de données réelles.

Cependant, si certains types de données et cas d’utilisation peuvent tirer parti de l’approche NoSQL, c’est parfois aux dépens de l’intégrité transactionnelle, de la souplesse d’indexation et de la facilité d’interrogation.

Pour compliquer encore les choses, le NoSQL ne constitue pas un type particulier de SGBD, mais une appellation qui regroupe quatre catégories principales de fonctions différentes :

  • Clé-valeur
  • Document
  • Colonnes
  • Graphique

À savoir :

Bien que plusieurs acteurs comme AWS et DataStax classifient les bases de données orientées colonnes comme des sous-catégories du NoSQL, certains considèrent que ce type de database renvoie davantage à une approche relationnelle, puisque les métadonnées, la compatibilité avec SQL et les transactions ACID sont gérées de la même manière que dans un SGBDR.

Il y a souvent une assimilation des bases de données « column store », SQL, et « wide column store », NoSQL. 
La différence se joue dans la manière de stocker les colonnes.
Dans l’approche « column store », chaque colonne est stockée séparément, alors que dans la seconde approche, celle adoptée pour Cassandra et BigTable, ce sont des familles de colonnes qui sont hébergées individuellement.  

Le SGBD en mémoire (In-Memory)

La dernière catégorie importante de SGBD à étudier est le SGBD en mémoire, ou In-Memory. Ce type de SGBD utilise principalement la mémoire pour stocker les données, au lieu de les stocker sur disque.

Ainsi, son principal usage vise à améliorer les performances. Comme les données sont conservées en mémoire, plutôt que sur disque, la latence d’E/S est fortement réduite. En effet, les mouvements mécaniques du disque, les délais de recherche et le transfert en mémoire tampon ne sont plus à prendre en compte puisque les données sont immédiatement accessibles en mémoire.

Par ailleurs, l’accès aux données en mémoire peut être optimisé, là où un SGBD traditionnel est optimisé pour un accès sur disque. Les produits SGBDIM diminuent la gestion induite : en effet, les algorithmes internes sont généralement plus simples et les instructions processeur (UC) moins nombreuses.

Outre les algorithmes, les éditeurs utilisent des technologies comme la mémoire persistante (PMEM) pour améliorer l’accessibilité des données et leur pérennité. En effet, des barrettes de mémoire vive et SSD spécifiques assurent la conservation des données même en cas de coupure de courant. Cette solution facilite les cas d’usage tels que l’IoT et le streaming des données. 

Cette technologie fortement poussée par Intel doit permettre aux éditeurs de proposer des solutions plus performantes, mais les prix restent pour l’instant plus élevés que de la mémoire vive classique.

Autres modèles de SGBD

Parmi les autres catégories de SGBD, le SGBD multimodèle, qui prend en charge plusieurs types de moteurs de stockage, gagne du terrain. De nombreuses offres NoSQL prennent en charge plusieurs modèles de données, tels que les documents et les paires clé-valeur.

Par ailleurs, les SGBDR évoluent vers une prise en charge des fonctionnalités NoSQL ; par exemple, par l’ajout d’une banque de colonnes à leur moteur relationnel.

Il existe encore d’autres catégories de SGBD, mais pas aussi répandues que les bases relationnelles, NoSQL et In-Memory :

  • Ainsi, les SGBD XML sont architecturés pour prendre en charge les données XML, similaires aux banques de documents NoSQL. Cependant, la plupart des SGBDR actuels offrent également une prise en charge XML.
  • Une base de données en colonnes est un système SQL optimisé pour accéder à plusieurs colonnes de nombreuses lignes simultanément en lecture (mais pas en écriture).
  • Populaires dans les années 1990, les SGBD orientés objet (OO) étaient conçus pour fonctionner avec les langages de programmation OO, un peu comme les banques de documents NoSQL.
  • Enfin, les SGBD antérieurs aux bases relationnelles comprennent des systèmes hiérarchiques (comme IBM IMS) et des systèmes réseau (comme CA IDMS), fonctionnant sur des systèmes mainframe de grande envergure. Les deux existent toujours et prennent en charge des applications héritées.

Autres considérations : plateforme, licence, CTO

En parcourant le paysage des SGBD, vous rencontrerez inévitablement de nombreuses autres questions requérant votre attention et, en tout premier lieu, celle de la plateforme.

Les environnements informatiques prédominants à l’heure actuelle sont Linux, Unix, Windows et le mainframe. Or, tous les SGBD ne sont pas pris en charge sur chacune de ces plateformes.

Autre considération qui a son importance : le fournisseur.

De nombreux SGBD sont open source, notamment dans le monde du NoSQL. L’approche open source augmente la flexibilité et réduit le coût de possession initial. Cependant, la prise en charge des logiciels open source laisse souvent à désirer, à moins d’acheter une distribution commerciale. Le coût total de possession peut également s’avérer plus élevé si l’on tient compte de l’administration, de la prise en charge et de l’exploitation en continu.

Vous pouvez également choisir d’alléger les dépenses d’acquisition et de prise en charge en faisant appel à une appliance de base de données ou à un déploiement dans le cloud. Une appliance est un SGBD préinstallé, vendu sur un matériel configuré et optimisé pour les applications de base de données. Le recours à une appliance peut abaisser considérablement le coût de la mise en œuvre et du support, car logiciel et matériel sont étudiés pour fonctionner ensemble.

La mise en œuvre de vos bases de données dans le cloud va encore plus loin. Au lieu d’implémenter un SGBD dans votre entreprise, vous pouvez souscrire un contrat auprès d’un prestataire de services de base de données en cloud.

Les opérateurs de cloud proposent des services managés qui dépendent d’un contrat annuel ou d’une utilisation purement à la consommation dite « as a service ». Souvent, ils mêlent les deux approches arguant qu’ils permettent aux clients d’étendre leur capacité de stockage et de traitement à la volée. Or il n’est pas toujours aisé d’évaluer les coûts de ces solutions : les tarifs affichés sont souvent liés à une offre en particulier.

Consulter la documentation permet de prendre conscience des spécificités des offres. Par exemple, AWS et propose une version gérée d’Apache Cassandra qui ne supporte pas les variantes de la base de données open source.

Étape suivante

Si votre entreprise envisage de s’équiper d’un SGBD, il est important de déterminer vos besoins précis, d’examiner les principaux SGBD dans chacune des catégories décrites plus haut, et de bien connaître les cas d’utilisation spécifiques pour lesquels chaque technologie est optimisée.

Pour approfondir sur Base de données

Close