Comment choisir le bon type de base de données pour votre entreprise

Il existe des centaines d'examens de bases de données à forte intensité technologique, mais ils ne donnent pas toujours des indications claires sur la première étape de la sélection d'une base de données: choisir le meilleur type général pour une application spécifique. Toutes les bases de données ne sont pas créées égales. Chacun a des forces et des faiblesses spécifiques. S'il est vrai qu'il existe des solutions de contournement pour faire fonctionner une base de données préférée pour la plupart des projets, l'utilisation de ces astuces ajoute une complexité inutile.

Avant d'envisager une base de données spécifique, prenez le temps de réfléchir au type qui prendrait le mieux en charge le projet en cours. La question va plus loin que «SQL vs NoSQL». Poursuivez votre lecture pour obtenir un aperçu des types de bases de données les plus courants, les mérites relatifs de chacun et comment déterminer celui qui convient le mieux.

Systèmes de gestion de bases de données relationnelles (Oracle, MySQL, MS Server, PostgreSQL)

Des bases de données relationnelles ont été développées dans les années 1970 pour gérer le flux croissant de données produites. Ils ont une théorie fondamentale solide et ont influencé presque tous les systèmes de bases de données utilisés aujourd'hui.

Les bases de données relationnelles stockent des ensembles de données sous forme de «relations»: des tables avec des lignes et des colonnes où toutes les informations sont stockées en tant que valeur d'une cellule spécifique. Les données d'un SGBDR sont gérées à l'aide de SQL. Bien qu'il existe différentes implémentations, SQL est standardisé et offre un niveau de prévisibilité et d'utilité.

Après qu'une première vague de fournisseurs ait tenté de tirer parti de la popularité du système avec des produits pas tout à fait relationnels, le créateur EF Codd a présenté un ensemble de règles qui doivent être suivies par tous les systèmes de gestion de bases de données relationnelles. Les 12 règles de Codd tournent autour de l'imposition de protocoles de structure interne stricts, garantissant que les recherches renvoient de manière fiable les données demandées et empêchant les modifications structurelles (au moins par les utilisateurs). Le cadre a garanti que les bases de données relationnelles sont cohérentes et fiables à ce jour.

Forces

Les bases de données relationnelles excellent dans la gestion de données hautement structurées et prennent en charge les transactions ACID (atomicité, cohérence, isolation et durabilité). Les données sont facilement stockées et récupérées à l'aide de requêtes SQL. La structure peut être mise à l'échelle rapidement car l'ajout de données sans modifier les données existantes est simple.

La création de limites sur ce que certains types d'utilisateurs peuvent accéder ou modifier est intégrée à la structure d'un SGBDR. Pour cette raison, les bases de données relationnelles sont bien adaptées aux applications qui nécessitent un accès à plusieurs niveaux. Par exemple, les clients peuvent consulter leurs comptes tandis que les agents peuvent à la fois afficher et apporter les modifications nécessaires.

Faiblesses

La plus grande faiblesse des bases de données relationnelles est le miroir de leur plus grande force. Aussi bons qu'ils soient dans la gestion des données structurées, ils ont du mal avec les données non structurées. Représenter des entités du monde réel dans leur contexte est difficile dans les limites d'un SGBDR. Les données «découpées» doivent être réassemblées à partir de tables en quelque chose de plus lisible, et la vitesse peut être affectée négativement. Le schéma fixe ne réagit pas bien au changement non plus.

Le coût est une considération avec les bases de données relationnelles. Ils ont tendance à être plus coûteux à installer et à développer. La mise à l'échelle horizontale, ou mise à l'échelle en ajoutant plus de serveurs, est généralement à la fois plus rapide et plus économique que la mise à l'échelle verticale, qui implique l'ajout de plus de ressources à un serveur. Cependant, la structure des bases de données relationnelles complique le processus. Le partage (où les données sont partitionnées horizontalement et distribuées sur un ensemble de machines) est nécessaire pour faire évoluer une base de données relationnelle. Le partage des bases de données relationnelles tout en maintenant la conformité ACID peut être un défi.

Utilisez une base de données relationnelle pour:

  • Situations où l'intégrité des données est absolument primordiale (c'est-à-dire pour les applications financières, la défense et la sécurité et les informations privées sur la santé)
  • Données hautement structurées
  • Automatisation des processus internes

Magasin de documents (MongoDB, Couchbase)

Un magasin de documents est une base de données non relationnelle qui stocke des données dans des documents JSON, BSON ou XML. Ils présentent un schéma flexible. Contrairement aux bases de données SQL, où les utilisateurs doivent déclarer le schéma d'une table avant d'insérer des données, les magasins de documents n'appliquent pas la structure du document. Les documents peuvent contenir toutes les données souhaitées. Ils ont des paires clé-valeur, mais incorporent également des métadonnées d'attributs pour faciliter les requêtes.

Forces

Les magasins de documents sont très flexibles. Ils gèrent bien les données semi-structurées et non structurées. Les utilisateurs n'ont pas besoin de savoir lors de la configuration quels types de données seront stockés, c'est donc un bon choix lorsqu'il n'est pas clair à l'avance quel type de données sera entrant.

Les utilisateurs peuvent créer la structure souhaitée dans un document particulier sans affecter tous les documents. Le schéma peut être modifié sans provoquer de temps d'arrêt, ce qui conduit à une haute disponibilité. La vitesse d'écriture est également généralement rapide.

Outre la flexibilité, les développeurs aiment les magasins de documents car ils sont faciles à mettre à l'échelle horizontalement. Le partitionnement nécessaire à la mise à l'échelle horizontale est beaucoup plus intuitif qu'avec les bases de données relationnelles, de sorte que les magasins de documents évoluent rapidement et efficacement.

Faiblesses

Les bases de données documentaires sacrifient la conformité ACID au profit de la flexibilité. De plus, même si l'interrogation peut être effectuée dans un document, elle n'est pas possible entre les documents.

Utilisez une base de données de documents pour:

  • Données non structurées ou semi-structurées
  • Gestion de contenu
  • Analyse approfondie des données
  • Prototypage rapide

Magasin de valeurs-clés (Redis, Memcached)

Un magasin clé-valeur est un type de base de données non relationnelle où chaque valeur est associée à une clé spécifique. Il est également connu sous le nom de tableau associatif.

La «clé» est un identifiant unique associé uniquement à la valeur. Les clés peuvent être tout ce qui est autorisé par le SGBD. Dans Redis, par exemple, les clés peuvent être n'importe quelle séquence binaire jusqu'à 512 Mo.

Les «valeurs» sont stockées sous forme d'objets blob et n'ont pas besoin de schéma prédéfini. Ils peuvent prendre presque toutes les formes: nombres, chaînes, compteurs, JSON, XML, HTML, PHP, binaires, images, courtes vidéos, listes et même une autre paire clé-valeur encapsulée dans un objet. Certains SGBD permettent de spécifier le type de données, mais ce n'est pas obligatoire.

Forces

Ce style de base de données a beaucoup de points positifs. Il est incroyablement flexible, capable de gérer facilement un très large éventail de types de données. Les clés sont utilisées pour accéder directement à la valeur sans recherche d'index ni jointure, les performances sont donc élevées. La portabilité est un autre avantage: les magasins de valeurs clés peuvent être déplacés d'un système à un autre sans réécriture de code. Enfin, ils sont hautement évolutifs horizontalement et ont globalement des coûts d'exploitation inférieurs.

Faiblesses

La flexibilité a un prix. Il est impossible d'interroger les valeurs, car elles sont stockées sous forme d'objets blob et ne peuvent être renvoyées qu'en tant que telles. Cela rend difficile la création de rapports ou la modification de parties de valeurs. Tous les objets ne sont pas non plus faciles à modéliser en tant que paires clé-valeur.

Utilisez un magasin clé-valeur pour:

  • Recommandations
  • Profils utilisateur et paramètres
  • Données non structurées telles que les critiques de produits ou les commentaires de blog
  • Gestion de session à grande échelle
  • Données qui seront consultées fréquemment mais pas souvent mises à jour

Magasin à colonnes larges (Cassandra, HBase)

Les magasins à colonnes larges, également appelés magasins de colonnes ou magasins d'enregistrements extensibles, sont des bases de données non relationnelles dynamiques orientées colonnes. Ils sont parfois considérés comme un type de magasin clé-valeur, mais ont également des attributs de bases de données relationnelles traditionnelles.

Les magasins à colonnes larges utilisent le concept d'espace de clés au lieu de schémas. Un espace de clés englobe des familles de colonnes (similaires aux tables mais plus flexibles dans la structure), chacune contenant plusieurs lignes avec des colonnes distinctes. Chaque ligne n'a pas besoin d'avoir le même nombre ou le même type de colonne. Un horodatage détermine la version la plus récente des données.

Forces

Ce type de base de données présente certains avantages des bases de données relationnelles et non relationnelles. Il traite mieux les données structurées et semi-structurées que les autres bases de données non relationnelles, et il est plus facile à mettre à jour. Comparé aux bases de données relationnelles, il est plus évolutif horizontalement et plus rapide à grande échelle.

Les bases de données en colonnes se compressent mieux que les systèmes basés sur des lignes. De plus, les grands ensembles de données sont simples à explorer. Les magasins à colonnes larges sont particulièrement efficaces pour les requêtes d'agrégation, par exemple.

Faiblesses

Les écritures coûtent cher dans le petit. Bien que la mise à jour soit facile à faire en masse, le téléchargement et la mise à jour des enregistrements individuels sont difficiles. De plus, les magasins à colonnes larges sont plus lents que les bases de données relationnelles lors du traitement des transactions.

Utilisez un magasin à colonnes larges pour:

  • Analyse de Big Data où la vitesse est importante
  • Entreposage de données sur le Big Data
  • Projets à grande échelle (ce style de base de données n'est pas un bon outil pour les applications transactionnelles moyennes)

Moteur de recherche (Elasticsearch)

Il peut sembler étrange d'inclure les moteurs de recherche dans un article sur les types de bases de données. Cependant, Elasticsearch a connu une popularité croissante dans ce domaine, car les développeurs recherchent des moyens innovants de réduire le délai de recherche. Elastisearch est une solution de stockage et de récupération de données non relationnelle, basée sur des documents, spécialement conçue et optimisée pour le stockage et la récupération rapide des données.

Forces

Elastisearch est très évolutif. Il présente un schéma flexible et une récupération rapide des enregistrements, avec des options de recherche avancées, notamment une recherche en texte intégral, des suggestions et des expressions de recherche complexes.

L'une des fonctionnalités de recherche les plus intéressantes est la racine. Stemming analyse la forme racine d'un mot pour trouver des enregistrements pertinents même lorsqu'une autre forme est utilisée. Par exemple, un utilisateur recherchant dans une base de données d'emploi des «emplois rémunérés» trouvera également des postes étiquetés «rémunérés» et «rémunérés».

Faiblesses

Elastisearch est davantage utilisé comme magasin intermédiaire ou supplémentaire que comme base de données primaire. Il a une faible durabilité et une mauvaise sécurité. Il n'y a pas d'authentification ni de contrôle d'accès innés. De plus, Elastisearch ne prend pas en charge les transactions.

Utilisez un moteur de recherche comme Elastisearch pour:

  • Amélioration de l'expérience utilisateur avec des résultats de recherche plus rapides
  • Enregistrement

Considérations finales

Certaines applications s'intègrent parfaitement dans les atouts d'un type de base de données spécifique, mais pour la plupart des projets, il y a chevauchement entre deux ou plus. Dans ces cas, il peut être utile de regarder quelles bases de données spécifiques dans les styles contestés sont de bons candidats. Les fournisseurs offrent un large éventail de fonctionnalités pour adapter leur base de données aux normes individuelles. Certains d'entre eux peuvent aider à résoudre l'incertitude sur des facteurs tels que la sécurité, l'évolutivité et le coût.