L’un des choix les plus essentiels à faire lors du développement d’une application est d’utiliser une base de données SQL ou NoSQL pour stocker les données. Les bases de données standard, c’est-à-dire les bases de données relationnelles qui utilisent SQL (Structured Query Language) pour les requêtes, sont le résultat de décennies de développement technologique, de bonnes pratiques et de tests de tension dans le monde réel. Ils sont développés pour les transactions de confiance et les demandes ad hoc, les éléments de base des applications métier. Ils sont également soumis à des contraintes, telles qu’un schéma rigide, qui les rendent moins adaptés à d’autres types d’applications.
Les bases de données NoSQL sont apparues en réaction à ces limitations. Les systèmes NoSQL stockent et gèrent les informations de manière à permettre une vitesse opérationnelle élevée et une grande flexibilité de la part des développeurs. Beaucoup d’entre eux ont été créés par des entreprises comme Google, Amazon, Yahoo et Facebook qui cherchaient de meilleures façons de stocker le contenu ou les informations de procédure pour d’énormes sites Web. Contrairement aux bases de données SQL, de nombreuses bases de données NoSQL peuvent être mises à l’échelle horizontalement sur des centaines ou des milliers de serveurs.
Les avantages de NoSQL ont un coût. Les systèmes NoSQL préfèrent la vitesse et l’évolutivité aux maisons ACID derrière des accords fiables assurés par des bases de données SQL. Et les métaphores utilisées pour traiter les données dans les systèmes NoSQL sont également relativement nouvelles, par rapport aux décennies de compréhension institutionnelle développée autour de SQL.
Les bases de données SQL et NoSQL offrent des compromis différents. Bien qu’ils puissent être complétés dans le contexte d’un projet spécifique – comme dans, lequel choisir pour cette application ou celle application – ils sont complémentaires dans l’image plus grande. Chacun est adapté à différents cas d’utilisation. La décision n’est pas vraiment un cas de soit/ou car il s’agit de savoir quel outil est idéal pour le travail.
NoSQL vs SQL
La différence essentielle entre SQL et NoSQL n’est pas tout ce qui est rendu complexe. Chacun a un point de vue différent sur la façon dont les informations doivent être stockées et récupérées.
Avec les bases de données SQL, toutes les informations ont une structure fondamentale. Une base de données standard comme Microsoft SQL Server, MySQL, PostgreSQL ou Oracle Database utilise un schéma— une signification formelle de la façon dont les informations insérées dans la base de données seront constituées. Par exemple, une certaine colonne dans une table peut être limitée à des nombres entiers uniquement. En conséquence, les données enregistrées sur bande dans la colonne auront un degré élevé de normalisation. Le schéma rigide d’une base de données SQL rend également relativement simple la réalisation d’agrégations sur les informations, par exemple en combinant les données de deux tables à l’aide de la commande SQL JOIN.
Avec NoSQL , les données peuvent être stockées dans un style sans schéma ou de forme libre. Toutes les données peuvent être conservées dans n’importe quel enregistrement. Parmi les bases de données NoSQL, vous découvrirez quatre conceptions courantes pour enregistrer des informations, qui entraînent quatre types typiques de systèmes NoSQL :
- Bases de données de documents (par exemple MongoDB). Les données placées sont enregistrées dans le type de structures JSON sans schéma, ou « fichiers », où les informations peuvent être n’importe quoi, des entiers aux chaînes en passant par le texte de forme libre. Il n’est pas nécessaire de spécifier de quels champs, le cas échéant, un fichier JSON sera composé.
- Magasins de clé-valeur (par exemple, Redis). Les valeurs de forme libre, des entiers simples ou des chaînes aux documents JSON complexes, sont accessibles dans la base de données au moyen de clés, telles que des chaînes.
- Grands magasins de colonnes (par exemple, Cassandra) . Les données sont stockées dans des colonnes au lieu de lignes comme dans un système SQL conventionnel. Toute variété de colonnes (et donc différents types d’informations) peut être regroupée ou agrégée selon les besoins pour les demandes ou les vues d’informations.
- Bases de données de graphes (par exemple, Neo4j). Les informations sont représentées sous la forme d’un réseau ou d’un graphique d’entités et de leurs relations, où chaque nœud du graphique est un bloc d’informations de forme libre.
Le stockage d’informations sans schéma est utile dans les cas suivants scénarios :
- Vous voulez un accès rapide aux informations, et vous vous souciez davantage de la rapidité et de la simplicité d’accès que des transactions fiables ou de la cohérence.
- Vous stockez un gros volume de données, et vous ne souhaitez pas vous enfermer dans un schéma, car la modification ultérieure du schéma pourrait être lente et angoissante.
- Vous recueillez des informations désorganisées provenant de plusieurs sources et vous souhaitez conservez les données dans leur forme d’origine pour une flexibilité maximale.
- Vous souhaitez enregistrer les données dans une structure hiérarchique, mais vous souhaitez que ces hiérarchies soient décrites par les données elles-mêmes, et non par un schéma externe. NoSQL permet aux données d’être nonchalamment autoréférentielles d’une manière qui est plus complexe à répliquer pour les bases de données SQL.
Interroger les bases de données NoSQL
Le langage de requête structuré utilisé par les bases de données relationnelles Les bases de données offrent une méthode uniforme pour interagir avec le serveur lors de la conservation et de la récupération des informations. La syntaxe SQL est extrêmement standardisée, donc bien que les bases de données privées puissent gérer certaines opérations de manière différente (par exemple, les fonctions de fenêtre), les bases restent exactement les mêmes.
En revanche, chaque base de données NoSQL a tendance à avoir sa propre syntaxe syntaxe d’interrogation et de traitement des données. CouchDB, par exemple, utilise des requêtes de type JSON, envoyées via HTTP, pour développer ou récupérer des documents à partir de sa base de données. MongoDB envoie des objets JSON via une procédure binaire, via une interface de ligne de commande ou une bibliothèque de langage.
Certains éléments NoSQL peuvent utiliser une syntaxe de type SQL pour traiter les données , mais seulement dans une mesure minimale. Par exemple, Apache Cassandra, un magasin à larges colonnes, possède son propre langage de type SQL, le Cassandra Question Language ou CQL. Une partie de la syntaxe CQL est directement issue du playbook SQL, comme les mots-clés SELECT ou INSERT. Cependant, il n’existe aucun moyen natif d’effectuer une SIGN UP WITH ou une sous-requête dans Cassandra, et par conséquent les mots-clés associés n’existent pas dans CQL.
Architecture sans partage
Une option de conception typique des systèmes NoSQL est une architecture « sans partage ». Dans un style sans partage, chaque nœud de serveur du cluster fonctionne individuellement de tous les autres nœuds. Le système n’a pas besoin d’obtenir l’accord d’autres nœuds pour renvoyer des données à un client. Les questions sont rapides car elles peuvent être renvoyées depuis le nœud le plus proche ou le plus pratique.
Un autre avantage d’un système sans partage est la résilience et la croissance évolutive. La mise à l’échelle du cluster est aussi simple que de faire tourner de nouveaux nœuds dans le cluster et d’attendre qu’ils se synchronisent avec les autres. Si un nœud NoSQL tombe en panne, les autres serveurs du cluster continueront de fonctionner. Toutes les informations restent disponibles, même si moins de nœuds sont facilement disponibles pour répondre aux requêtes.
Gardez à l’esprit qu’un style sans partage n’est pas unique aux bases de données NoSQL. De nombreux systèmes SQL standard peuvent être établis en mode sans partage, comme MySQL, bien que cela implique normalement de sacrifier la cohérence dans l’ensemble du cluster pour les performances.
Limites de NoSQL
Si NoSQL le permet beaucoup de liberté et de flexibilité, pourquoi ne pas abandonner complètement SQL ? La réponse simple est que de nombreuses applications nécessitent toujours le type de restrictions, de cohérence et de protections fournies par les bases de données SQL. Dans ces cas, certains « avantages » de NoSQL peuvent se transformer en inconvénients. D’autres restrictions proviennent du fait que les systèmes NoSQL manquent de fonctions particulières considérées comme approuvées dans le domaine SQL.
Pas de schéma
Même si vous prenez des informations sous forme libre, vous exiger d’appliquer des restrictions sur l’information pour la rendre utile. Avec NoSQL, l’imposition de contraintes inclut le déplacement de la responsabilité de la base de données vers le concepteur de l’application. Par exemple, le concepteur peut imposer une structure via un système de mappage relationnel des objets, ou ORM. Si vous souhaitez que le schéma vive avec les informations elles-mêmes, NoSQL ne le prend généralement pas en charge.
Certains services NoSQL offrent des systèmes facultatifs de saisie et de reconnaissance des données pour les informations. Apache Cassandra, par exemple, possède une multitude de types d’informations natifs qui rappellent ceux trouvés dans le SQL traditionnel.
Cohérence ultime
Les systèmes NoSQL utilisent l’option d’échanger une cohérence forte ou immédiate pour beaucoup meilleure accessibilité et efficacité. Les bases de données conventionnelles garantissent que les opérations sont atomiques (toutes les parties d’une transaction réussissent, ou aucune ne réussit), constantes (tous les utilisateurs ont la même vue des données), séparées (les offres ne sont pas en concurrence) et résilientes (une fois terminées, elles subiront une panne de serveur).
Ces quatre propriétés résidentielles ou commerciales, désignées conjointement en tant qu’ACID, peut être géré différemment dans les systèmes NoSQL. Plutôt que d’exiger une forte cohérence à travers le cluster, ce qui retarderait nécessairement les actions sur les requêtes, vous pouvez opter pour la cohérence ultime, qui permet de servir les requêtes sans attendre que les compositions actuelles soient copiées vers d’autres nœuds du groupe. Les données insérées dans le cluster sont finalement facilement disponibles partout, mais vous ne pouvez pas garantir quand.
Pour certains systèmes NoSQL, vous pouvez choisir parmi un certain nombre de compromis entre cohérence et vitesse, bien que ce qui est disponible varier entre les produits. Azure Universe DB de Microsoft, par exemple, vous permet de choisir un niveau de cohérence par demande, afin que vous puissiez sélectionner le comportement qui correspond à votre cas d’utilisation. La sémantique de transaction, qui dans un système SQL garantit que toutes les actions d’une transaction (par exemple, effectuer une vente et minimiser le stock) sont soit terminées soit annulées, est proposée dans certains systèmes NoSQL, tels que MongoDB.
Verrouillage NoSQL
La majorité des systèmes NoSQL sont conceptuellement comparables, mais implémentés différemment. Chacun a tendance à avoir ses propres métaphores et mécanismes sur la façon dont les données sont interrogées et traitées.
L’un des effets négatifs de cela est un degré éventuellement élevé de couplage entre le raisonnement de l’application et la base de données. Ce couplage n’est pas si mauvais si vous choisissez un système NoSQL et que vous vous y tenez, mais il peut devenir une pierre d’achoppement si vous changez de système en cours de route.
Si vous migrez, par exemple, depuis MongoDB vers CouchDB (ou vice versa), vous devez faire plus que simplement migrer des informations. Vous devez également naviguer dans les distinctions entre l’accès aux données et les métaphores programmatiques. Pour le dire simplement, vous devez reformuler les parties de votre application qui accèdent à la base de données.
Capacités NoSQL
Un autre inconvénient de NoSQL est le manque relatif d’expertise. Là où le marché des talents SQL standard est assez vaste, le marché des compétences NoSQL est naissant.
À titre de recommandation, Indeed.com rapporte que depuis 2022, le volume des listes de tâches pour les bases de données SQL conventionnelles : MySQL, Microsoft SQL Server, Oracle Database, etc. reste supérieur au volume de tâches pour MongoDB, Couchbase et Cassandra. La demande de compétences NoSQL reste une partie du marché des compétences SQL.
Fusionner SQL et NoSQL
Nous pouvons nous attendre à ce que certaines des différences entre les systèmes SQL et NoSQL disparaissent progressivement. Actuellement, de nombreuses bases de données SQL acceptent désormais les documents JSON comme type d’informations natif et peuvent effectuer des requêtes par rapport à ces informations. Certains ont même des moyens natifs d’imposer des restrictions sur les données JSON, afin qu’elles soient gérées avec la même rigueur que les données conventionnelles en ligne et en colonne.
D’un autre côté, les bases de données NoSQL ajoutent non seulement SQL -comme les langages de questions, mais aussi d’autres fonctionnalités des bases de données SQL conventionnelles, telles que les propriétés ACID de MongoDB.
Il est probable que les futures générations de bases de données, ainsi que les futures variations des systèmes de bases de données actuels, chevaucheront le paradigmes et utilisent à la fois les performances SQL et NoSQL, ce qui contribue à rendre le monde des bases de données moins fragmenté. Par exemple, Azure Cosmos DB de Microsoft utilise un ensemble de primitives sous le capot pour reproduire de manière interchangeable les habitudes des deux types de systèmes. Google Cloud Spanner combine SQL et une forte cohérence avec l’évolutivité horizontale des systèmes NoSQL.
Pourtant, les systèmes SQL pur et NoSQL pur auront leur emplacement pendant plusieurs années à venir. Visez NoSQL dans les situations où la flexibilité de style, l’évolutivité horizontale et la haute disponibilité sont des facteurs plus vitaux à prendre en compte qu’une forte cohérence de lecture et d’autres protections typiques des bases de données SQL. Pour de nombreuses applications, ces garanties pourraient bien mériter d’être échangées contre ce que NoSQL propose.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
