
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.
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.
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.
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.
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.
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 !