Vers SQL ou NoSQL? Telle est la question.

Il y a beaucoup de confusion et de battage médiatique concernant les technologies de persistance. Il peut être difficile de choisir le bon. Les considérations sont nombreuses et chaque situation nécessite une enquête approfondie. Dans cet article, nous allons prendre une vue de 10 000 pieds pour vous aider à vous orienter dans ce paysage. Pour tirer le meilleur parti de cette discussion, vous aurez besoin d'une compréhension de base des bases de données relationnelles (SQL), documentaires et graphiques. Nous discuterons du compromis entre flexibilité et performances et identifierons où ces technologies se situent sur ce spectre. Et enfin, je vais vous fournir des recommandations et d’autres ressources pour vous aider à déterminer la meilleure technologie pour le travail.

Qu'y a-t-il dans un nom? Flexibilité et performances

SQL signifie «langage de requête structuré» et NoSQL signifie «non seulement SQL», mais pour nos besoins, il est plus utile de le considérer comme «aucun langage de requête structuré». Les bases de données SQL prennent en charge un langage de requête riche et les données sont structurées sous une forme générique pour continuer à poser une grande variété de questions. De nombreuses bases de données NoSQL ont un langage de requête limité et les données sont structurées pour répondre à un nombre limité de questions. NoSQL est plus rapide car il est optimisé pour répondre à moins de questions.

C'est vraiment aussi simple que cela. Il n’existe pas de sauce secrète qui rend NoSQL plus rapide que SQL. Les performances des requêtes sont le produit de la correspondance entre votre structure de données et les questions posées. Si la structure des données correspond à la question, la requête fournit la réponse rapidement. Mais lorsque la question posée est différente de la structure des données, des transformations sont appliquées et le «rendu» de la réponse prend plus de temps. Les bases de données NoSQL peuvent être plus rapides que SQL car la question et la réponse sont pré-rendues ou intégrées dans la structure de données. Ainsi, au lieu d'interroger les données avec NoSQL, nous récupérons des réponses prédéfinies à des questions bien connues. Le degré auquel les requêtes sont intégrées à la structure de données varie selon la technologie. De toute évidence, de nombreux facteurs doivent être pris en compte lors de l’évaluation des performances, mais le fait de reconnaître que les performances sont au détriment de la flexibilité des requêtes est un bon point de départ.

Données de pré-rendu

Données de pré-rendu ou préparation de la question et réponse dans la structure de données est ce qui rend NoSQL rapide. Mais que signifie pré-rendre les données? Les données de pré-rendu appliquent des transformations d'opinion avant que les données ne soient conservées. Comparez cela avec la persistance des données sous une forme générique, puis l'application d'une transformation d'opinion lors de l'accès aux données.

L'image ci-dessus montre le processus de "Pré-rendu" des données dans une base de données de document NoSQL. (1) Les données sous leur forme «naturelle» sont (2) transformées en une forme d'opinion qui correspond aux questions de la candidature. (3) Les données sont persistantes et lors de l'accès (4), aucune transformation n'est requise car les données ont été pré-rendues pour notre objectif spécifique. La réponse à la question "Quels produits, éléments de campagne et métadonnées existent pour le bon de commande X?" a été intégré à la structure de données. Ce document ne peut pas répondre à la question "Quels sont les produits dans le rayon des chaussures?" Pour cela, nous avons besoin d'un autre document.

Comparez cela avec l'image ci-dessus d'une base de données SQL avec un pré-rendu limité. (1) Les données sous leur forme «naturelle» (2) subissent peu ou pas de transformation avant d'être (3) conservées dans la base de données sous une forme générique. (4) Lors de l'accès aux données, elles sont transformées pour correspondre à la structure requise pour l'application. Cette transformation en temps réel est plus coûteuse, mais elle est plus flexible car les données génériques peuvent être transformées pour répondre à diverses questions. Cette structure de données peut répondre à la fois: "Quels produits, éléments de campagne et métadonnées existent pour le bon de commande X?" et "Quels sont les produits dans le rayon des chaussures?" mais pas avec la même vitesse et la même échelle qu'une base de données de documents.

Accélérez votre intranet SharePoint avec Rise

Découvrez comment tirer le meilleur parti de votre investissement dans Office 365 with Rise, l'offre Intranet-as-a-Service de Perficient en réduisant la durée de projet de votre intranet avec des solutions prêtes à l'emploi, en diminuant les risques de votre projet et en augmentant la valeur de votre intranet.

Obtenez le guide

Ce est une connaissance puissante, car nous pouvons considérablement modifier les performances de notre application en modifiant l'endroit où les données sont transformées. Il y a de nombreuses conséquences et effets en cascade lorsque nous faisons cela, donc ce changement ne doit pas être effectué par hasard. Un effet secondaire courant est la dénormalisation, la duplication des données et la cohérence éventuelle, nécessitant des modèles d'accès complexes ou une logique de synchronisation.

And Then There Were Graphs

Jusqu'à présent, nous avons discuté de deux technologies de base de données aux extrêmes de la flexibilité et spectre de performances, bases de données SQL relationnelles et bases de données de documents NoSQL. Les bases de données Graph sont une offre relativement nouvelle dans l'espace NoSQL. Certains ont suggéré qu'ils constituent la base de données ultime et peuvent être utilisés pour résoudre n'importe quel problème. Ce n’est tout simplement pas vrai. Comme les autres bases de données NoSQL, les bases de données de graphes sont des outils spéciaux qui troquent la flexibilité pour la performance. Il existe plusieurs types de base de données de graphiques, mais le plus populaire, et celui dont nous parlerons ici, est le graphe de sommet étiqueté. C'est ce à quoi la plupart des gens pensent lorsqu'ils parlent de base de données de graphiques. À première vue, une base de données de graphes peut apparaître comme une base de données de documents relationnels. Combinaison du meilleur du SQL relationnel avec des documents NoSQL. Cependant, les bases de données graphiques ne sont pas un sur-ensemble de ces technologies. Au lieu de cela, ils se situent entre eux sur le spectre de la flexibilité et de la performance. Comme d’autres bases de données NoSQL, la valeur unique d’une base de données de graphes provient du fait d’intégrer certaines optimisations et de limiter les types de questions que nous pouvons poser rapidement.

Considérez le graphique ci-dessus. Nous avons deux approches différentes pour modéliser la relation entre une compétence et sa catégorie: les arêtes à gauche et les propriétés des sommets à droite. Vous pouvez supposer que le graphique de gauche est préféré car il modélise les relations à l'aide d'une arête. Mais si vous posiez la question: «Quelles compétences existe-t-il dans la catégorie linguistique?» l'interrogation des données sur la gauche coûterait deux fois plus cher que l'interrogation des données sur la droite, en supposant que vous exécutez cette requête dans un Azure Cosmos DB. À l'instar des autres bases de données NoSQL, une base de données de graphes doit intégrer la logique de requête appropriée pour fonctionner rapidement. Et différents fournisseurs proposent différentes optimisations. Lors de la modélisation d’une base de données de graphiques, il est extrêmement important de comprendre les questions posées sur les données. Nous pouvons ensuite le modéliser pour répondre rapidement à ces questions en incorporant une partie de la logique de requête dans la structure du modèle.

Les bases de données de graphiques ont un langage de requête riche et offrent beaucoup de flexibilité de modélisation. Par exemple, en stockant la catégorie en tant que relation d'arête et en tant que propriété sur le sommet, nous introduisons des options de requête supplémentaires, mais nous introduisons également la duplication des données. Les graphiques sont un excellent outil si vous posez les bonnes questions au bon modèle. Si vous vous demandez si un graphique est le bon outil pour votre cas d'utilisation, voici une question simple pour vous guider: "Les relations sont-elles plus importantes que les données?" Si tel est le cas, c'est un bon indicateur qu'un graphique peut être le bon outil.

Résumé

Il existe une grande variété de bases de données dans l'espace NoSQL. Et différents fournisseurs ont optimisé leurs bases de données, intégrant des caractéristiques de performances uniques. Considérez une base de données SQL relationnelle comme un couteau suisse et les bases de données NoSQL comme des outils spéciaux et performants qui doivent être utilisés habilement. Chaque base de données peut fonctionner correctement ou mal en fonction de la structure des données et de la nature des questions. Une performance plus élevée nécessite généralement une compréhension des questions à l'avance. Il intègre ou pré-rend les réponses dans des structures de données spécialisées qui correspondent plus étroitement à la structure de la question; cela offre de meilleures performances au détriment de la flexibilité. Il n’ya pas de solution miracle. Associer une base de données à un problème de domaine nécessite une évaluation réfléchie des questions que vous vous poserez.

Notre approche

Le groupe de développement personnalisé Perficient est spécialisé dans le développement de solutions personnalisées. Donc «fichier> nouveau projet» est monnaie courante. Beaucoup de nos clients innovent et créent des produits uniques. Cela signifie souvent que nous, et eux, découvrons leur domaine de produits au fur et à mesure. Nous retardons les décisions concernant les technologies de persistance aussi longtemps que possible, créant souvent des parties de l'application avant de s'engager dans une approche. Une fois que nous comprenons mieux les besoins et les caractéristiques de performance, nous pouvons sélectionner la bonne technologie pour le travail. Une base de données SQL relationnelle est un point de lancement courant car elle offre plus de flexibilité et peut être bien modélisée sans connaître toutes les questions que nous poserons d’emblée. Au fur et à mesure que les fonctionnalités nécessitant une optimisation sont identifiées, nous étudions des solutions NoSQL qui répondent à ces besoins spécifiques. De nombreuses solutions cloud modernes reposent sur diverses technologies de persistance; SQL reste un excellent outil, et NoSQL offre de nouvelles options pour gérer les données à l'échelle mondiale.

Nous sommes des technologues qui aiment profondément connecter les gens avec des solutions logicielles qui enrichissent leur vie. N'hésitez pas à nous contacter pour partager votre vision et discuter de la manière dont nous pouvons vous aider à la concrétiser.

Ressources supplémentaires

Voici quelques ressources supplémentaires pour vous aider dans votre exploration de NoSQL.

SQL vs . NoSQL Explained – YouTube

A Skeptics Guide to Graph Databases – David Bechberger – YouTube

À propos de l'auteur

Nathan est un architecte de solutions senior depuis plus de 14 ans d'expérience dans la conception et la création d'applications personnalisées. Il a étudié le design industriel et connaît Illustrator, mais son travail le plus créatif est réalisé avec un IDE. Il a une vaste expérience du full-stack, adore .NET et explore constamment de nouvelles technologies.

Plus de cet auteur