Choisissez votre base de données NoSQL

Critères de comparaison des BdD NoSQL

Lorsqu'on se lance dans un projet de développement, choisir la bonne base de données NoSQL est une décision stratégique qui peut significativement impacter la réussite de votre projet car elle aura un impact sur la performance, la scalabilité et la stabilité de la future application.

Nous avons vu que contrairement aux bases de données relationnelles qui suivent un modèle général applicable à diverses situations, les bases de données NoSQL sont souvent spécialisées pour répondre à des besoins spécifiques (clé/valeur, orientée colonne, documents, graphes…). Elles ne sont pas interchangeables. Changer de base de données plus tard à un coût considérable donc il faut partir sur de bonnes “bases” (sans jeu de mots 🙂).

Vous vous rappelez du théorème de CAP ?

  • Cohérence (Consistency) : Toutes les requêtes après une opération d’écriture reçoivent la même valeur, quel que soit le nœud interrogé.

  • Disponibilité (Availability) : La base de données répond toujours aux demandes, même en cas de défaillance.

  • Tolérance de partition (Partition Tolerance) : Le système continue de fonctionner même si la communication entre certains nœuds est interrompue.

Eh bien en fonction de vos priorités, vous devrez choisir une base de données qui privilégie deux de ces trois caractéristiques :

  • Pour le couple CA (cohérence et disponibilité), on utilisera des bases de données relationnelles traditionnelles (Oracle, MySQL, PostgreSQL).

  • Pour le couple CP (cohérence et tolérance de partition), on choisira des technologies comme MongoDB, HBase ou BigTable.

  • Pour le couple AP (disponibilité et tolérance de partition), on privilégiera des solutions comme Cassandra, CouchBase ou Redis.

Voyons les critères fondamentaux pour vous permettre de faire votre choix :

1/Modèle de données et structure des informations

Le modèle de données est probablement le critère le plus déterminant dans le choix d’une base de données NoSQL.

Questions à se poser :

  • Quelle est la structure de mes données ?

  • Comment mes données sont-elles reliées entre elles ?

  • Mes données sont-elles homogènes ou hétérogènes ?

2/Performance et scalabilité

Les performances et la capacité à monter en charge sont des critères essentiels, particulièrement pour les applications à fort trafic.

Questions à se poser :

  • Quel volume de données prévois-je de gérer ?

  • Combien d’utilisateurs simultanés devrais-je supporter ?

  • Ma charge de travail est-elle principalement orientée lecture ou écriture ?

  • Quelles sont mes exigences en termes de temps de réponse ?

3/Cohérence et gestion des transactions

Le niveau de cohérence requis et la gestion des transactions sont des aspects critiques à considérer.

Questions à se poser :

  • Mon application nécessite-t-elle des transactions ACID ?

  • Puis-je accepter une cohérence éventuelle (eventually consistent) ?

  • Quels niveaux de cohérence la base de données me permet-elle de configurer ?

  • Comment la base gère-t-elle les conflits d’écriture ?

4/Langage de requêtage et facilité d’utilisation

La richesse du langage de requête et la facilité d’utilisation influencent directement la productivité des développeurs.

Questions à se poser :

  • Quelle est la complexité des requêtes que je dois effectuer ?

  • La base propose-t-elle des fonctionnalités d’agrégation et d’analyse ?

  • Existe-t-il des outils d’administration et de visualisation ?

  • La documentation est-elle complète et à jour ?

  • La base supporte-t-elle des opérations de jointure ou équivalentes ?

5/Disponibilité et tolérance aux pannes

La capacité de la base de données à rester disponible même en cas de défaillance est cruciale pour de nombreuses applications.

Questions à se poser :

  • Quelle est la criticité de la disponibilité pour mon application ?

  • Comment la base de données gère-t-elle la réplication des données ?

  • Comment s’effectue la récupération après une panne ?

6/Coût et licences

Les considérations financières incluant les coûts de licence, d’hébergement et de maintenance.

Questions à se poser :

  • Quel est mon budget pour les licences et l’infrastructure ?

  • Est-ce que je préfère une solution open source ou commerciale ?

  • Quels sont les coûts d’exploitation à long terme ?

  • La base est-elle disponible en tant que service géré dans le cloud ?

  • Existe-t-il des coûts cachés (support, fonctionnalités premium) ?

7/Écosystème et support

L’écosystème autour d’une base de données, incluant les outils, les bibliothèques et le support communautaire ou commercial.

Questions à se poser :

  • Existe-t-il des bibliothèques avec les langages de programmation que je connais et maîtrise ?

  • La base de données est-elle activement maintenue et développée ?

  • Y a-t-il une communauté active pour obtenir de l’aide ?

  • Existe-t-il des formations et certifications disponibles ?

  • Quelles entreprises utilisent cette base de données en production ?

Découvrons ensemble comment utiliser ces critères dans vos projets.

Spécifiez vos besoins

Pour choisir méthodiquement la base de données NoSQL la plus adaptée à votre projet, utilisez une approche structurée en plusieurs étapes.

A. Analyse des besoins fonctionnels

Commencez par définir clairement les besoins fonctionnels de votre application:

  • Cartographiez les types de données que vous allez stocker

  • Identifiez les structures et relations entre ces données

  • Définissez les exigences en termes de cohérence des données

  • Établissez les priorités entre performance, cohérence et disponibilité

B. Analyse des contraintes techniques

Identifiez ensuite les contraintes techniques qui pourraient influencer votre choix:

  • Volumes de données attendus (actuels et futurs)

  • Nombre d’utilisateurs concurrents

  • Exigences de performance (temps de réponse, débit)

  • Contraintes d’infrastructure (hébergement dans vos locaux, dans le cloud, etc.)

  • Compétences disponibles dans votre équipe

C. Évaluation comparative structurée

Créez ensuite une matrice de décision en listant les bases de données NoSQL candidates et en les évaluant selon les critères pertinents pour votre projet. Attribuez des poids à chaque critère en fonction de son importance relative (moi je note souvent entre 0 et 4). 

Ci-dessous je vous ai mis un exemple de structure que j’utilise pour faire mon choix. Le point important à noter est que j’attribue un poids à chaque critère selon son importance pour les besoins du projet. La somme totale des poids doit être égale à 5 pour que cette matrice fonctionne.

Un poids de 0 signifie que ce critère n’a aucune importance, et une note supérieure à 2,5 qu’il est primordial (i.e. il représente à lui seul la moitié des critères) :

Poids

MongoDB

Cassandra

Redis

Adéquation au modèle de données

1

4

4

4

Capacité à monter en charge (Performance et scalabilité)

0.5

4

2

2

Niveau de cohérence requis

0.5

2

4

3

Richesse du langage de requêtage

1

4

2

3

Disponibilité et tolérance aux pannes

1

4

2

4

Coût et licences

0.25

4

1

4

Qualité du support et de la communauté

0.5

4

1

4

Mon expérience sur cette base

0.25

4

1

0

Total

5

19

12

16,5

D. Preuve de concept

Pour les options les plus prometteuses, réalisez une preuve de concept avec un sous-ensemble représentatif de vos données et des cas d’utilisation critiques :

  • Implémentez un prototype avec chaque base de données ;

  • Testez les performances dans des conditions proches de la réalité ;

  • Évaluez la facilité de développement et d’administration ;

  • Identifiez les limitations potentielles et les risques.

En suivant cette méthodologie et en vous posant ces questions clés, vous serez en mesure de faire un choix éclairé qui répond aux besoins spécifiques de votre projet pour garantir sa réussite à long terme.

Faîtes votre veille sur DBEngines

Pour finir en beauté, voici un petit bonus pour vous aider à faire votre choix. Le site DB-Engines.org est une vraie mine d’or pour explorer les bases de données disponibles sur le Web. Il ne se contente pas de fournir les caractéristiques techniques de chaque solution : il évalue aussi leur présence et leur influence à travers un scoring.

AD_4nXeeBTj2pzEEjRGCSOYn22CrfMXID-aapxB5r3Nzwo0S8i7t0T7cjeiNbRy_bw1TH67dwuRIQrUdajY2GMj8neLHSfJ7_nFE0eIiAFhavEvekhLTDiGdJIX6tKGqNKiP7s4LPY9Oyg?key=7n72Od3YUxXHWa8QCk8BOCNK

Ce score est calculé en prenant en compte des données comme les tickets Stack Overflow (bugs, solutions, conseils), les blogs, tutoriels, et même leur usage en entreprise rapporté dans des architectures. Ce score est précieux pour détecter les tendances, que ce soit pour les développeurs en quête de la bonne technologie ou pour les entreprises souhaitant investir. Certes, cela reste une vision biaisée basée sur les informations publiques, mais ça offre déjà une base solide pour réfléchir et poser les bonnes questions.

Enfin, n’oubliez pas qu’il n’existe pas de solution universelle. Dans certains cas, la meilleure approche peut même être d’utiliser plusieurs types de bases de données NoSQL dans une architecture polyglotte, où chaque base de données est utilisée pour ce qu’elle fait de mieux.

 

🎧 Derrière l’écran

Dans l’entretien à suivre, Alexandre nous partage la façon dont il réalise ses choix technologiques entre les différents types de bases de données pour assurer la réussite de ses projets de développement.

En résumé

  • Comprenez votre modèle de données et choisissez une base de données qui s’y adapte naturellement.

  • Identifiez vos priorités en termes de cohérence, disponibilité et tolérance aux partitions (théorème CAP).

  • Évaluez vos besoins de performance et de scalabilité actuels et futurs.  

  • Considérez la facilité d’utilisation, l’écosystème et les coûts à long terme.

Écrivez ici une phrase de transition pour présenter le prochain chapitre !

Ever considered an OpenClassrooms diploma?
  • Up to 100% of your training program funded
  • Flexible start date
  • Career-focused projects
  • Individual mentoring
Find the training program and funding option that suits you best