Bien choisir son type de base de données

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

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.