Quelles sont les différences entre NoSQL et un SGBDR classique?

71

Au cours des derniers mois, NoSQL a été fréquemment mentionné dans les nouvelles techniques. Quelles sont ses caractéristiques les plus importantes par rapport à un SGBDR classique? A quel niveau (physique, logique) les différences se produisent-elles?

Où sont les meilleurs endroits pour utiliser NoSQL? Pourquoi?

nosql rdbms database-recommendation

— Spredzy
source

61

NoSQL signifie "Pas seulement SQL" et signifie généralement que la base de données n'est pas une base de données relationnelle, qui a été très populaire au cours des dernières décennies.

La raison pour laquelle NoSQL est si populaire ces dernières années est principalement due au fait qu’une base de données relationnelle créée à partir d’un serveur n’est plus aussi simple à utiliser. En d'autres termes, ils ne sont pas très performants dans un système distribué. Tous les grands sites que vous avez mentionnés, tels que Google, Yahoo, Facebook et Amazon (je ne connais pas beaucoup Digg), contiennent beaucoup de données et les stockent dans des systèmes distribués pour plusieurs raisons. Il se peut que les données ne tiennent pas sur un serveur ou que la haute disponibilité soit requise .

Théorème de la PAC

Les propriétés d'un système distribué peuvent être décrites par le théorème CAP . Sur les trois propriétés, vous ne pouvez avoir que deux au maximum:

La cohérence
Une disponibilité
tolérance au réseau P artitionnement

Amazon Dynamo utilise la cohérence éventuelle pour se rapprocher des trois propriétés. Le document Dynamo: le magasin de valeurs de clés hautement disponibles d'Amazon mérite d'être lu pour en savoir plus sur les bases de données NoSQL et les systèmes distribués. Amazon Dynamo a les propriétés A et P.

Google adopte une approche différente avec BigTable , qui possède les propriétés C et A.

Autres bases de données NoSQL

Comme je l'ai écrit au début, il existe de nombreux autres types de bases de données NoSQL, conçues pour répondre à différentes exigences. Par exemple, des bases de données graphiques telles que Neo4j , des bases de documents telles que CouchDB et des bases de données multimodèles / objets telles que OrientDB .

Enfin, je voudrais dire que les bases de données relationnelles resteront populaires. Ils sont très flexibles et maintenables. Mais ils ne sont pas toujours le meilleur choix.

— Jonas
source

1

Bonne réponse exhaustive.

— TML

NoSQL ne signifie PAS non-relationnel, cela signifie simplement autre chose qu'un SGBD SQL.

— nvogel

1

Il semble que lors de la récente conférence O'Reilly Strata, Mark Madsen ait inventé une nouvelle interprétation de "NoSQL" dans son historique des bases de données dans le but de remplacer "Not Only SQL". C'est maintenant: "Non, SQL" ;-)

— Lukas Eder

6

"Non seulement" était une modernisation, le mouvement NoSQL au début était furieusement opposé aux bases de données relationnelles. Ensuite, ils ont frappé le monde réel.

— Gaius

22

NoSQL est un terme très large et est généralement désigné comme signifiant "Pas seulement SQL." Le terme cesse de gagner en popularité dans la communauté des non-SGBDR.

Vous constaterez que la base de données NoSQL a peu de caractéristiques communes. Ils peuvent être grossièrement divisés en quelques catégories:

magasins de clés / valeur
Bases de données inspirées de Bigtable (basées sur le document Google Bigtable)
Bases de données inspirées du dynamo
bases de données distribuées
bases de documents

C'est une question énorme, mais le présent sondage sur les bases de données distribuées y répond assez bien .

Pour une réponse courte:

Les bases de données NoSQL peuvent se passer de diverses parties d'ACID afin d'obtenir certains autres avantages - tolérance aux partitions, performances, répartition de la charge ou mise à l'échelle de manière linéaire avec l'ajout de nouveau matériel.

Quant à savoir quand les utiliser, cela dépend entièrement des besoins de votre application.

— Jérémie Peschka
source

12

NoSQL est une sorte de base de données qui n'a pas de schéma fixe comme le fait un SGBDR classique. Avec les bases de données NoSQL, le schéma est défini par le développeur au moment de l'exécution. Ils n'écrivent pas d'instructions SQL normales dans la base de données, mais utilisent plutôt une API pour obtenir les données dont ils ont besoin. Les bases de données NoSQL peuvent généralement évoluer facilement sur différents serveurs physiques sans qu'il soit nécessaire de savoir sur quel serveur se trouvent les données que vous recherchez.

Cependant, il y a quelques compromis pour toute cette flexibilité: les bases de données NoSQL manquent assez de fonctionnalités comparées aux systèmes SGBDR tels que SQL Server, Oracle, DB2, MySQL, etc. Il n'y a pas de Service Broker, de journalisation des transactions, de packages ETL, etc.

NoSQL n'est pas quelque chose de nouveau. Il existe depuis 50 ou 60 ans. À l'époque, cela s'appelait COBOL. Même idée exacte, juste un groupe différent est venu avec.

— mrdenny
source

3

Le point 1 est incorrect pour beaucoup (toutes?) De bases de données NoSQL, sauf si vous lui avez explicitement dit que vous ne vous souciez pas de la réussite de l'écriture. Par exemple, n'importe quelle base de données sauvegardée par Hadoop écrira les données à trois endroits différents. Par défaut, Cassandra écrira sur trois emplacements et accusera réception de l’écriture comme réussie lorsque deux auront réussi.

— Jeremiah Peschka

3

Comment gère-t-il les accès simultanés lors de ces mises à jour? Existe-t-il une transaction de type distribué entre eux ou l'écriture est-elle traitée au préalable et les serveurs gèrent-ils le reste en arrière-plan?

— mrdenny

La simultanéité dépend entièrement de la mise en œuvre. Riak utilise des horloges vectorielles pour garantir la simultanéité. En cas d'écritures conflictuelles, elles peuvent être renvoyées à l'application appelante pour être résolues. D'autres utilisent une dernière écriture gagne.

— Jeremiah Peschka le

En ce qui concerne l’accusé de réception en écriture - dans la plupart des cas, les écritures ne sont pas reconnues tant que le système d’exploitation n’en a pas accusé réception. Vous pouvez même aller jusqu'à demander l'acquittement d'écritures durables, ce qui signifie que les bits sont réellement vidés sur le disque au lieu d'être dans la mémoire tampon du système d'exploitation. MongoDB reconnaît les écritures en mémoire par défaut, mais peut être configuré pour exiger un accusé de réception d'écriture sur le disque. La réplication est gérée différemment avec chaque produit. Avec Hadoop, le client écrit sur le serveur A qui écrit sur B, qui écrit sur C. Une fois que C a répondu, l’écriture est terminée et le client reçoit un accusé de réception en écriture.

— Jeremiah Peschka

Dans ce cas, je suis corrigé. J'ai supprimé la déclaration incorrecte. Ai-je FUBAR autre chose?

— mrdenny

6

Le fait de se passer de la configuration relationnelle, des clés primaires et étrangères et des frais généraux supplémentaires liés au maintien de la sécurité transactionnelle vous permet souvent d’obtenir une augmentation extrême des performances. Toutefois, cela n’est pas propre aux nouvelles bases de données / banques de données, par exemple, MySQL a été configuré pour fonctionner aux "niveaux NoSQL" en contournant les couches.

En bref, vous pouvez souvent obtenir des performances impressionnantes si vous acceptez de prendre le risque de perdre des données. La plupart des systèmes NoSQL le font. Par exemple, MongoDB organise les modifications de données à écrire lorsque cela vous convient. Les données elles-mêmes sont sécurisées et sécurisées sur le plan des transactions, mais conservées dans une mémoire volatile. Si vous perdez de la puissance, vous ne pouvez pas être sûr à 100% de ne pas avoir perdu de données ou de données corrompues.

C'est un compromis entre sécurité et performance.

— Johanna Larsson
source

5

L' entrée Wikipedia est un bon point de départ . Au lieu de cela, en liant les données d’une table à une autre, vous stockez les objets sous forme de paires clé / valeur et il n’existe aucun schéma de base de données; ils sont gérés dans le code.

Quelques sites utilisent simultanément NoSQL et les serveurs de SGBDR typiques, mais pour stocker des données différentes. Donc, vous n'avez pas à choisir l'un ou l'autre.

— steve.lippert
source

Le fait que le gros de cette question puisse être résolu en allant à WP me fait me frotter le menton alors que je contemple les réponses ici. Je pense que c'est un peu trop "question de remplissage" mais c'est vraiment tout ce que nous avons pour le moment.

— jcolebrand

1

La remarque importante ici est que la prise en charge des relations de suppression (clé étrangère) dans l'infrastructure de base de données / serveur soulage la base de données / serveurs de la charge de travail et de la gestion de la gestion des verrous liée au maintien de l'intégrité référentielle. La conséquence de ceci, le compromis, est que l’intégrité référentielle, la cohérence et les autres préoccupations concernant ACID sont ensuite renvoyées aux applications. De nombreuses applications en bénéficient plutôt que d'être limitées par celle-ci. (Certaines applications doivent être calées dans le modèle client / serveur).

— Jim Dennis

0

J'ai beaucoup travaillé sur la base de données MongoDB NoSQL et Oracle.

Schéma

La base de données SQL possède son propre schéma prédéfini pour stocker des données structurées.

Dans la base de données NoSQL, il n'y a pas de schéma prédéfini, ici le schéma est l'élément le plus dynamique basé sur les éléments de données.

L'évolutivité

Les bases de données SQL sont évolutives verticalement, ce qui signifie que si nous voulons mettre à l'échelle la base de données SQL, nous devons donner une impulsion matérielle sur laquelle le système de SGBD est installé. C’est là que s’appliquent parfois la limitation de l’extensibilité.

Les bases de données NoSQL sont évolutives horizontalement, ce qui signifie que si nous voulons les faire évoluer, nous devons ajouter plus de nœuds et créer un réseau de distribution basé sur nos propres besoins et la puissance requise. Voici comment ils réduisent la charge sur la base de données

Récupération de données

Dans les bases de données SQL, pour définir et manipuler des données, nous pouvons utiliser le langage SQL (Structured Query Language), qui est très puissant de nos jours.

En termes de base de données NoSQL, les requêtes se concentrent sur la collection et les documents. Parfois, cela s'appelle UnQL (Unstructured Query Language). Ceci est toujours dans la phase d'évolution et varie donc d'un fournisseur à l'autre de la base de données NoSQL.

Pour plus d'informations sur les principales différences, mon blog: Différence entre les bases de données SQL et NoSQL

— Virat Gaywala
source