Récemment, NoSQL a acquis une immense popularité.
Quels sont les avantages de NoSQL par rapport aux SGBDR traditionnels ?
Réponses:
Toutes les données ne sont pas relationnelles. Pour ces situations, NoSQL peut être utile.
Cela dit, NoSQL signifie "Not Only SQL". Il n'est pas destiné à frapper SQL ou à le supplanter.
SQL présente plusieurs très gros avantages:
Ceux-ci ne sont pas partis.
C'est une erreur de penser à cela comme un argument soit / soit. NoSQL est une alternative que les gens doivent considérer quand cela convient, c'est tout.
Les documents peuvent être stockés dans des bases de données non relationnelles, comme CouchDB.
Peut-être que lire ceci aidera.
SELECT blob FROM images WHERE blob CONTAINS('red car'). Ainsi, même si vous pouvez stocker les données brutes dans la base de données, vous ne pouvez pas les rechercher sans y attacher des métadonnées. Les modules de recherche en texte intégral dans les systèmes SGBDR comblent une partie de l'écart semi-structurel.
L'histoire semble ressembler à ceci:
Google a besoin d'une couche de stockage pour son index de recherche inversé. Ils pensent qu'un SGBDR traditionnel ne va pas le couper. Ils implémentent donc un magasin de données NoSQL, BigTable au-dessus de leur système de fichiers GFS. L'essentiel est que des milliers de machines matérielles bon marché fournissent la vitesse et la redondance.
Tout le monde réalise ce que Google vient de faire.
Le théorème CAP de Brewers est prouvé. Tous les systèmes SGBDR utilisés sont des systèmes CA. Les gens commencent également à jouer avec les systèmes CP et AP. Les magasins K / V sont beaucoup plus simples, ils sont donc le principal véhicule de la recherche.
Les systèmes Software-as-a-Service en général ne fournissent pas de magasin de type SQL. Par conséquent, les gens s'intéressent davantage aux magasins de types NoSQL.
Je pense qu'une grande partie du décollage peut être liée à cette histoire. La mise à l'échelle Google a pris de nouvelles idées chez Google et tout le monde emboîte le pas, car c'est la seule solution qu'ils connaissent actuellement au problème de mise à l'échelle. Par conséquent, vous êtes prêt à tout retravailler autour de l'idée de base de données distribuée de Google, car c'est le seul moyen de passer au-delà d'une certaine taille.
C - Cohérence
A - Disponibilité
P - Tolérance de partition
K / V - Clé / Valeur
NoSQL est meilleur que le SGBDR pour les raisons / propriétés suivantes de NoSQL
ÉDITER:
Pour répondre «pourquoi le SGBDR ne peut pas évoluer», veuillez consulter le pdf des frais généraux du SGBDR rédigé par Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden et Michael Stonebraker
Les SGBDR ont des difficultés à gérer d'énormes volumes de données de téraoctets et de péta octets . Même si vous disposez d'un réseau redondant de disques indépendants / peu coûteux (RAID) et d'un déchiquetage de données, il ne s'adapte pas bien à un énorme volume de données. Vous avez besoin de matériel très coûteux.
Journalisation : l' assemblage d'enregistrements de journaux et le suivi de toutes les modifications des structures de base de données ralentissent les performances. La journalisation peut ne pas être nécessaire si la récupérabilité n'est pas une exigence ou si la récupérabilité est fournie par d'autres moyens (par exemple, d'autres sites sur le réseau).
Verrouillage : le verrouillage traditionnel en deux phases représente une surcharge importante puisque tous les accès aux structures de base de données sont régis par une entité distincte, le gestionnaire de verrouillage.
Verrouillage : dans une base de données multithread, de nombreuses structures de données doivent être verrouillées avant de pouvoir y accéder. La suppression de cette fonctionnalité et le passage à une approche à un seul thread a un impact notable sur les performances.
Gestion des tampons : un système de base de données de mémoire principale n'a pas besoin d'accéder aux pages via un pool de tampons, ce qui élimine un niveau d'indirection à chaque accès aux enregistrements.
Cela ne signifie pas que nous devons utiliser NoSQL sur SQL.
Pourtant, le SGBDR est meilleur que NoSQL pour les raisons / propriétés suivantes du SGBDR
Nous devons utiliser RDBMS (SQL) et NoSQL (pas seulement SQL) en fonction de l'analyse de rentabilisation et des exigences
NOSQL n'a pas d'avantages particuliers par rapport au modèle de base de données relationnelle. NOSQL répond à certaines limitations des SGBD SQL actuels, mais n'implique aucune fonctionnalité fondamentalement nouvelle par rapport aux modèles de données précédents.
NOSQL signifie seulement pas de SQL (ou "pas seulement SQL") mais cela ne signifie pas la même chose que pas de relationnel . Une base de données relationnelle constituerait en principe une très bonne solution NOSQL - c'est juste qu'aucun de l'ensemble actuel de produits NOSQL n'utilise le modèle relationnel.
Le SGBDR se concentre davantage sur les relations et NoSQL se concentre davantage sur le stockage.
Vous pouvez envisager d'utiliser NoSQL lorsque votre SGBDR atteint des goulots d'étranglement. NoSQL rend le SGBDR plus flexible.
Le plus grand avantage de NoSQL par rapport au SGBDR est l' évolutivité .
Les bases de données NoSQL peuvent facilement évoluer vers de nombreux nœuds, mais pour le SGBDR, c'est très difficile.
L'évolutivité vous offre non seulement plus d'espace de stockage, mais également des performances beaucoup plus élevées, car de nombreux hôtes fonctionnent en même temps.
Juste en ajoutant à toutes les informations données ci-dessus
Avantages NoSql:
1) NoSQL est bon si vous voulez être prêt pour la production rapidement en raison de sa prise en charge de l'architecture sans schéma et orientée objet.
2) Les bases de données NoSql sont finalement cohérentes, ce qui dans un langage simple signifie qu'elles ne fourniront aucun verrou sur les données (documents) comme dans le cas du SGBDR et ce que cela signifie est que le dernier instantané des données est toujours disponible et augmente ainsi la latence de votre application .
3) Il utilise la stratégie MVCC (Multi view concurrency control) pour maintenir et créer un instantané de données (documents).
4) Si vous souhaitez avoir des données indexées, vous pouvez créer une vue qui indexera automatiquement les données en fonction de la définition de vue que vous fournissez.
Inconvénients de NoSql:
1) Il ne convient certainement pas aux grandes applications transactionnelles lourdes car il est finalement cohérent et ne prend pas en charge les propriétés ACID.
2) En outre, il crée plusieurs instantanés (révisions) de vos données (documents) car il utilise la méthodologie MVCC pour le contrôle de la concurrence, à la suite de quoi l'espace est consommé plus rapidement qu'auparavant, ce qui rend le compactage et donc la réindexation plus fréquents et ralentit votre réponse de l'application à mesure que les données et les transactions de votre application augmentent. Pour contrer cela, vous pouvez mettre à l'échelle horizontalement les nœuds, mais encore une fois, il sera plus coûteux de comparer la base de données SQL.
De mongodb.com :
Les bases de données NoSQL diffèrent des anciennes technologies relationnelles dans quatre domaines principaux:
Modèles de données : une base de données NoSQL vous permet de créer une application sans avoir à définir le schéma au préalable contrairement aux bases de données relationnelles qui vous obligent à définir votre schéma avant de pouvoir ajouter des données au système. Aucun schéma prédéfini ne rend les bases de données NoSQL beaucoup plus faciles à mettre à jour à mesure que vos données et vos exigences changent.
Structure des données : les bases de données relationnelles ont été construites à une époque où les données étaient assez structurées et clairement définies par leurs relations. Les bases de données NoSQL sont conçues pour gérer des données non structurées (par exemple, des textes, des publications sur les réseaux sociaux, des vidéos, des e-mails) qui constituent une grande partie des données qui existent aujourd'hui.
Mise à l'échelle : il est beaucoup moins coûteux de mettre à l'échelle une base de données NoSQL qu'une base de données relationnelle, car vous pouvez ajouter de la capacité en évoluant sur des serveurs de base bon marché. Les bases de données relationnelles, en revanche, nécessitent un seul serveur pour héberger l'intégralité de votre base de données. Pour évoluer, vous devez acheter un serveur plus gros et plus cher.
Modèle de développement : les bases de données NoSQL sont open source tandis que les bases de données relationnelles sont généralement des sources fermées avec des frais de licence intégrés à l'utilisation de leurs logiciels. Avec NoSQL, vous pouvez démarrer sur un projet sans aucun investissement lourd en frais de logiciel à l'avance.