Les bases de données relationnelles ont été utilisées pendant des décennies pour stocker des données, et elles représentent toujours une solution viable pour de nombreux cas d'utilisation. NoSQL quant à lui est choisi aujourd'hui notamment pour des raisons d'évolutivité et de performance. Cet article est une interview de Dipti Borkar, directrice de la gestion produit chez Couchbase, sur les défis, les avantages et le processus de migration d'un SGBDR vers NoSQL.
InfoQ: Quand est-il temps de remplacer SQL par une solution NoSQL?
Dipti Borkar: OK, ce titre semble un peu sévère - et en vérité, dans la plupart des cas, il ne s'agit pas de remplacer SQL par une solution NoSQL, mais plutôt, de faire une transition de l'un à l'autre, si l'application et le cas d'utilisation dictent la nécessité d'un changement. En général, cette transition sera stimulée par le besoin de flexibilité - à la fois dans le modèle de scalabilité et le modèle de données - lorsque l'on construit des applications web modernes et des applications mobiles.
Les applications web typiques sont construites avec une architecture trois tiers. Pour supporter la charge, plus de serveurs Web sont simplement ajoutés derrière un load balancer pour supporter plus d'utilisateurs. La capacité à monter en charge est un principe fondamental dans le monde du cloud computing, de plus en plus important, dans lesquels des instances de machines virtuelles peuvent être facilement ajoutées ou enlevées pour répondre à la demande.
Cependant, quand il s'agit de la couche de données, les bases de données relationnelles (SGBDR) ne permettent pas un passage à l'échelle simple et ne fournissent pas un modèle de données flexible. Gérer plus d'utilisateurs signifie l'ajout d'un plus grand serveur et les gros serveurs sont très complexes, propriétaires et d'un coût disproportionné, contrairement au matériel à faible coût, les "commodity hardware", des architectures sur le cloud. Les organisations commencent à voir les problèmes de performance avec leurs bases de données relationnelles pour les applications existantes ou nouvelles. D'autant plus que le nombre d'utilisateurs augmente, ils se rendent compte de la nécessité d'une base plus rapide et plus flexible. C'est le moment de commencer à évaluer NoSQL et l'adopter comme base de données dans leurs applications Web.
InfoQ: Quelles seraient les principales étapes requises pour la transition de SQL à NoSQL?
Dipti Borkar: Les organisations / projets peuvent varier considérablement en fonction de ce qu'ils recherchent dans une base de données NoSQL, la transition dépendra donc de votre cas d'utilisation. Voici des lignes directrices générales pour la transition:
1 Comprendre les exigences clés pour votre application:
Voici certaines exigences correspondant au besoin d'avoir une base NoSQL:
- Développement rapide d'applications
- Évolution des besoins du marché
- Modification des besoin en termes de données
- Évolutivité
- La demande d'utilisateur n'est pas connu au départ
- Nécessité d'un débit constamment croissant pour ajouter et mettre à jour des données
- Une performance constante
- Faible temps de réponse pour une meilleure expérience utilisateur
- Haut débit pour gérer la croissance virale
- La fiabilité de fonctionnement
- Haute disponibilité pour gérer les erreurs avec un impact minimal sur l'application
- APIs de monitoring intégrés pour une meilleure maintenance
2 Comprendre les différents types d'offres NoSQL:
Il y a un mythe commun que toutes les bases de données NoSQL sont créées égales - ce n'est pas vrai. Cassandra, par exemple, peut être une solution que vous utilisez pour de l'analyse de données compte tenu de son modèle en colonnes. Neo4j, une base de données graphe, par exemple, peut être la base de données que vous utilisez pour les applications qui ont besoin d'accéder à des relations entre les entités.
Je vais me concentrer spécifiquement sur les bases de données NoSQL orientées document - avec Couchbase et MongoDB qui sont les deux exemples les plus connus et les plus largement adoptés.
3 Réaliser un prototype
Une fois que vous avez réduit les choix possibles pour le type de base de données, développez un prototype intégrant les principales caractéristiques de votre application. Évaluez les temps de réponse, les performances en terme de débit et la capacité à monter en charge facilement.
4 Modélisation de document et développement
Pour les bases de données orientées documents, passez quelques jours sur la modélisation de vos données en partant de schémas fixes tabulaires pour arriver vers des modèles de document flexibles.
5 Déploiement en recette puis production
La stabilité opérationnelle est un aspect très important pour les applications web interactives. Tester et recetter votre déploiement comme vous le feriez pour des applications qui utilisent les systèmes traditionnels de SGBDR. Assurez-vous que la base de données sélectionnée prend en charge le monitoring au sein du cluster, qu'elle permet une mise à l'échelle facile avec l'ajout de capacité si besoin.
6 Tenez-vous au courant des dernières tendances
Il existe une pléthore de formations gratuites de qualité qui offrent des cours pratiques pour se former sur NoSQL. La meilleure façon d'assurer une mise en œuvre réussie de NoSQL est d'avoir une équipe de développement qui est à jour sur les dernières versions du serveur et des offres des fournisseurs.
Voici des liens vers quelques-uns des plus gros:
InfoQ: Quelles sont les principales difficultés de migration de SQL à NoSQL?
Dipti Borkar: La principale difficulté se résume essentiellement à comprendre les différences entre les systèmes SGBDR traditionnels et les bases de données documents. La différence la plus importante est le modèle de données:
Comme indiqué ci-dessus, chaque enregistrement dans une base de données relationnelle est conforme à un schéma - avec un nombre fixe de champs (colonnes) ayant chacun un objet spécifié et un type de données. Chaque enregistrement est le même. Les données sont dénormalisées dans plusieurs tables. L'avantage est qu'il y a moins de données en double dans la base de données. L'inconvénient est qu'un changement dans le schéma signifie effectuer plusieurs "alter table" coûteux qui exigent de verrouiller plusieurs tables simultanément afin d'assurer qu'un changement ne laisse pas la base de données dans un état incohérent.
Avec les bases de données documents, d'autre part, chaque document peut avoir une structure complètement différente des autres documents. Aucune gestion supplémentaire n'est nécessaire sur la base de données pour gérer les changements sur les schémas.
InfoQ: Quels sont les avantages des bases de données NoSQL documents?
Dipti Borkar: Les principaux avantages des bases de données documents sont les suivants:
- Modèle de données flexible Les données peuvent être insérées sans un schéma défini, et le format des données qui sont insérées peut changer à tout moment, fournissant ainsi une flexibilité extrême, ce qui, en définitive, permet une agilité importante pour le métier
- Évolutivité facile Certaines bases de données NoSQL propagent automatiquement les données entre les serveurs, ne nécessitant pas la participation des applications. Les serveurs peuvent être ajoutés et supprimés sans interruption des applications, avec des données et des I/O répartis sur plusieurs serveurs.
- Consistent, haute performance Les technologies avancées de bases de données NoSQL mettent des données en cache, de manière transparente, dans la mémoire système; un comportement qui est complètement transparent pour le développeur et l'équipe en charge des opérations.
InfoQ: Comment les développeurs réagissent quand vous leur parlez de l'adoption de NoSQL?
Dipti Borkar: Les développeurs sont très enthousiastes sur les technologies NoSQL notamment en raison de la facilité de développement que ces bases de données apportent. Les bases de données documents disposent de schémas extrêmement flexibles et il est facile de travailler avec.
Les développeurs peuvent plus rapidement effectuer des changements dans leurs applications sans avoir besoin de modifier le schéma de la base de données sous-jacente. Ceci est particulièrement utile lorsque les développeurs construisent des applications avec des données éparses, en constante évolution ou provenant de fournisseurs tiers sur lesquels ils n'ont pas de contrôle.
InfoQ: Est-il acceptable de travailler avec les développeurs existants et de leur faire acquérir de nouvelles compétences ou devez-vous rechercher directement des experts NoSQL?
Dipti Borkar: Les développeurs d'applications vont trouver cela facile d'adopter certaines technologies NoSQL, en particulier celles qui utilisent JSON pour le format du document. De plus en plus de développeurs utilisent JSON dans leurs applications. Par conséquent stocker les données directement en JSON dans la base de données est plus cohérent
Les développeurs qui utilisent beaucoup SQL auront peut être besoin de s'adapter et d'apprendre les approches de modélisation de documents. Repenser la manière dont les données peuvent être structurées de façon logique à l'aide des documents plutôt que de normaliser les données dans un schéma de base de données fixe devient un aspect important.
InfoQ: Avez-vous eu ou entendu parler de tentatives infructueuses pour passer à NoSQL? Si oui, quel est le problème?
Dipti Borkar: Les architectes et les développeurs doivent s'assurer que leurs besoins essentiels sont satisfaits par la solution ou la base de données sélectionnée. Par exemple, choisir une base de données adaptée à des applications analytiques ne va pas forcément satisfaire les besoins en terme de latence et de débit nécessaire dans le cas des applications interactives. Les projets qui font un choix rapide sans rechercher toutes les exigences peuvent se rendre compte ensuite qu'ils ont des temps de réponse plus lents pour accéder aux données conduisant ainsi à une expérience utilisateur médiocre. Les utilisateurs ont besoin de planifier à l’avance l'évolutivité de leur modèle. Voici un exemple plus drastique. Dans certaines situations, une application s'est propagée de manière virale, mais la base de données qui a été choisie ne pouvait pas suivre le rythme et tenir la charge.
Dans le même temps, utiliser une base de données plus adaptée pour du transactionnel risque de ne pas être un bon choix pour les travaux d'analyse avancées ou de traitement complexe.Une solution Big Data peut être plus appropriée.
InfoQ: Quels sont les principaux enseignements d'une migration vers NoSQL?
Dipti Borkar: Il y a beaucoup d'avantages pour un développeur à passer à NoSQL. Un modèle de données plus souple et la liberté vis-à-vis des schémas rigides est un gros avantage. Vous pouvez également voir une performance nettement améliorée et la capacité de scaler horizontalement au niveau de la couche de données.
Mais la plupart des produits NoSQL n'en sont qu'aux premiers stades du cycle du produit. Pour des fonctionnalités telles que des jointures complexes ou transactions sur plusieurs documents, les développeurs devraient peut être mieux d'utiliser un SGBDR traditionnel. Et pour certains projets, une approche hybride pourrait être le meilleur choix.
A propos de la personne interviewée
Dipti Borkar est la directrice de la gestion produit chez Couchbase où elle est responsable de la roadmap de Couchbase Server, une base de données NoSQL. Elle travaille avec les clients et les utilisateurs pour comprendre les exigences émergentes pour ce qui concerne la faible latence, les bases de données évolutives. Dipti possède une vaste expérience technique dans l'industrie des bases ayant travaillé chez IBM en tant qu'ingénieur logiciel et directeur du développement pour l'équipe serveur DB2 puis à MarkLogic comme chef de produit senior. Dipti est titulaire d'une maîtrise en informatique de l'Université de Californie de San Diego avec une spécialisation en bases de données et titulaire d'un MBA de la Haas School of Business de l'Université de Californie de Berkeley.