Pourquoi NoSQL est-il plus rapide que SQL?

48

Récemment, on m'a demandé:

Pourquoi NoSQL est-il plus rapide que SQL?

Je n'étais pas d'accord avec la prémisse de la question ... c'est un non-sens pour moi personnellement. Je ne vois aucune amélioration des performances en utilisant NoSQL au lieu de SQL. Peut-être que SQL sur NoSQL, oui mais pas de cette façon.

Est-ce que je manque quelque chose à propos de NoSQL?

performance nosql

— cnd
source

3

Si vous ne pouvez pas voir une amélioration des performances, c'est ce que vous dites. Le fait est que la plupart des solutions NoSQL renoncent à une (ou à plusieurs) des propriétés ACID d'une base de données relationnelle, elles en font donc moins.

— Oded

1

Certains flux de travail (et structures de données) ne peuvent pas être facilement mappés vers une base de données relationnelle traditionnelle activée par ACID. Pour ceux-ci, vous pouvez voir d’ énormes augmentations de performances en utilisant une base de données NoSQL. Cependant, si vous prenez simplement une base de données SQL existante (bien conçue) et la mettez dans une base de données NoSQL, vos performances en souffriront sûrement .

— Joachim Sauer

1

La réponse est: a-t-il été établi comme plus rapide? Et plus vite dans quoi? Temps de développement? Temps de lecture? Écrire le temps? Quel type d'écriture? À quoi le comparons-nous? Requêtes multi-tables? Les jointures?

— Rolf

65

Il existe de nombreuses solutions NoSQL, chacune avec ses forces et ses faiblesses. Par conséquent, les mesures suivantes doivent être prises avec un grain de sel.

Cependant, de nombreuses bases de données NoSQL reposent sur la dénormalisation et tentent d’optimiser pour le cas dénormalisé. Par exemple, supposons que vous lisiez un article de blog avec ses commentaires dans une base de données orientée document. Souvent, les commentaires sont enregistrés avec le message lui-même. Cela signifie qu'il sera plus rapide de les récupérer tous ensemble, car ils sont stockés au même endroit et vous n'avez pas à effectuer de jointure.

Bien sûr, vous pouvez faire la même chose en SQL et la dénormalisation est une pratique courante lorsque l’on a besoin de performances. C'est juste que beaucoup de solutions NoSQL sont conçues dès le début pour être toujours utilisées de cette façon. Vous obtenez alors les compromis habituels: par exemple, l'ajout d'un commentaire dans l'exemple ci-dessus sera plus lent car vous devez enregistrer le document entier avec celui-ci. Et une fois que vous avez dénormalisé, vous devez veiller à préserver l'intégrité des données dans votre application.

De plus, dans de nombreuses solutions NoSQL, il est impossible de faire des jointures arbitraires, donc des requêtes arbitraires. Certaines bases de données, telles que CouchDB, nécessitent que vous réfléchissiez à l'avance aux requêtes dont vous aurez besoin et que vous les prépariez dans la base de données.

Au total, cela revient à attendre un schéma dénormalisé et à optimiser les lectures pour cette situation, ce qui fonctionne bien pour des données peu relationnelles et nécessitant beaucoup plus de lectures que d'écritures.

— Andrea
source

4

Soit dit en passant, ceci peut être réalisé avec une simple vue matérialisée, ou une couche de cache, tout en bénéficiant de toutes les qualités SQL. Tout ce qui est correctement modélisé est relationnel et la duplication de données logiques n’est pas une solution (la vue mat est une duplication mais pas une duplication logique car c’est simplement une image de quelque chose d’autre).

— Morg.

Comme je l'ai dit dans la réponse, on peut faire la même chose en SQL; c'est simplement que lorsque cela devient la règle au lieu de l'exception, les bases de données NoSQL sont généralement plus rapides et plus naturelles à utiliser. En théorie, SQL est le meilleur modèle que l'on puisse utiliser, mais lorsque les données dépassent une certaine taille, il ne peut tout simplement pas s'adapter à certains modèles et la duplication des données devient plus rapide et plus facile à raisonner.

— Andrea

3

C'est un taureau. Le modèle relationnel couvre tout ce que vous pouvez créer dans NoSQL et bien plus encore. Le seul avantage de NoSQL est qu’une approche simple et incohérente de la mise à l’échelle est intégrée et facile à utiliser. Cela n'a rien à voir avec SQL et tout à voir avec le fait de ne pas se soucier des propriétés d'ACID. Vous pouvez avoir des tâches de synchronisation entre noeuds SQL indépendants qui auront exactement les mêmes propriétés (très mauvaises) de mise à l'échelle et de cohérence que les magasins NoSQL. La différence est que les nœuds SQL peuvent également avoir une cohérence si vous le souhaitez.

— Morg.

1

Que se passe-t-il si vous avez 5 milliards de millions de lignes de données et que vous souhaitez obtenir le commentaire de chacune d'elles, sous certaines conditions? Ne serait-il pas plus rapide si vous aviez un index sur le champ de commentaire de la table avec SQL? L’indexation en texte intégral améliorerait encore cette situation.

— Jwize

@morg - "Le modèle relationnel couvre tout ce que vous pouvez créer dans NoSQL et bien plus encore." Non, pas vraiment. Il existe de nombreux exemples de types de données qui correspondent si mal au modèle relationnel que le forcer à y insérer des données entraîne une inefficacité massive. Exemple: un jeu en ligne dispose d'une installation permettant de stocker l'inventaire des joueurs. Les joueurs ont un ensemble fini d’emplacements numérotés, chacun pouvant stocker un ou plusieurs éléments d’un type spécifique. Il existe environ 50 types d'articles, chacun ayant 4 à 6 attributs associés, avec un peu de chevauchement, donc il y a environ 80 attributs possibles ...

— Jules

27

La chose qui vous manque à propos de NoSQL est que NoSQl ne peut en aucun cas être comparé à SQL. NoSQL est le nom de toutes les technologies de persistance qui ne sont pas SQL. Les bases de données de document, les bases de données clé-valeur et les bases de données d'événement sont tous des systèmes NoSQL. Ils sont tous différents dans presque tous les aspects, que ce soit la structure des données enregistrées, les requêtes, les performances et les outils disponibles.

Donc, si quelqu'un vous pose une telle question en entrevue, cela devrait être la réponse.

— Euphorique
source

4

S'il y a une caractéristique qui tue de NoSQL, je dirais que c'est l'évolutivité. C'est pourquoi les Facebook et les Googles l'utilisent. En raison du volume gigantesque de données. NoSQL: lorsque vous devez gérer d'énormes quantités de données.

— Pieter B

16

Les bases de données 'NoSQL' (ou plus précisément: non relationnelles) renoncent à certaines fonctionnalités des bases de données traditionnelles pour des raisons de rapidité, mais surtout pour une évolutivité horizontale.

Les fonctionnalités manquantes dépendent du produit concret. En général, les propriétés ACID complètes ou même les opérations de jointure ne sont pas prises en charge. C'est le prix pour la performance accrue.

— Karl
source

1

Décrire NoSQL comme non relationnel n'est pas plus précis. Il existe d'autres anciennes bases de données non relationnelles qui ne font pas partie de la catégorie NoSQL. NoSQL signifie beaucoup plus que non relationnel. Lisez ceci pour plus d’informations: martinfowler.com/bliki/NosqlDefinition.html

— eddyP23

8

Vous avez raison, il serait insensé de le dire dans une déclaration générale. Ce qui est probablement le point entier; Au lieu d'une seule réponse, l'intervieweur s'attend probablement à ce que vous répondiez avec des questions vous permettant de comprendre le contexte du problème (quel type de données, quelle quantité, dans quel environnement d'exploitation, etc.), la solution NoSQL spécifique . Ils essaieront de savoir comment vous analysez les problèmes et, en cours de route, auront une idée de vos connaissances sur les différentes solutions existantes.

— Eelco
source

Oui, il s’agit d’une déclaration générale, et si nous l’acceptons comme telle, la réponse à la question est: cela dépend.

— Rolf

5

Les bases de données NoSQL n'ont normalement de sens que si vous concevez vos données autour d'elles.

Si vous avez l’intention de les utiliser simplement comme remplacement du SGBDR, vous obtiendrez peut-être moins de performances que plus, en particulier si vous n’avez pas assez de budget pour payer des serveurs avec beaucoup de RAM.

Regardez cet article qui compare l'utilisation de l'espace disque MySQL avec celui de MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage

— Clifford
source

3

Quelle base de données NoSQL? Quelle base de données SQL? Si quelqu'un vous dit que NoSQL est plus rapide que SQL, vous devriez vous en aller. Ou mieux encore, regardez cette vidéo:

http://www.youtube.com/watch?v=b2F-DItXtZs

Je ne dirai pas que la moitié des affirmations sur NoSQL sont fausses, mais je dirai qu'il existe beaucoup de fanboyismes NoSQL parmi ceux qui ne le comprennent vraiment pas très bien.

Bien que SQL ait ses limites (bien sûr), il s’agit également d’une technologie très mature, bien comprise, et qui compte un grand nombre de développeurs qui comprennent bien son utilisation. Je ne peux pas en dire autant pour toutes les formes de NoSQL.

— Zachary K
source

-2

NoSql supporté par les bases de données orientées colonnes où le SGBDR est une base de données orientée lignes ... (Support NoSQL). Si un client / client écrit une requête pour obtenir les détails moyens sur l'âge ou la rémunération à partir des enregistrements des employés de 1Lakh ... que se passe-t-il?

Dans les SGBDR, il va contourner chaque ligne et collecter la valeur et la somme et la division pour obtenir le résultat. En ce qui concerne la base de données Columnar, nul besoin de s’inquiéter de toutes les itérations d’une ligne lakh. Mais ne vous occupez que d’une seule ligne qui est plus rapide à calculer. Ainsi, parfois, NoSQL est plus rapide que SQL. Cette affaire NoSQL ne se soucie pas des plaintes ACID valent la peine!

— kiran teja avvaru
source

2

J'ai un peu corrigé la mise en forme, bien que je ne sois pas sûr de ce que vous essayez de faire entre les deux. Et ACID n'est pas toujours supporté par le SGBDR.

-3

Oubliez la théorie autour des bases de données…. Une fois que vous avez compris vos requêtes, vous pouvez enregistrer des données dans nos bases de données de la manière exacte dans laquelle elles sont réellement utilisées dans votre application….

Par exemple, prenons cet exemple, vous avez un modèle client avec de nombreuses commandes et de nombreux articles associés à chaque commande, ils ont également de nombreux articles sauvegardés pour des achats ultérieurs ... si vous êtes un grand magasin de commerce électronique avec 10 millions de clients et 50 million de commandes. Et ce client se connecte à son tableau de bord qui affiche ces données exactes. Quelle quantité de travail une base de données SQL doit-elle effectuer pour rechercher le client, joindre les commandes, ainsi que chaque élément de campagne et les éléments enregistrés. Dans une base de données SQL, toutes ces données devront probablement être jointes d'une manière ou d'une autre ... ou vous pouvez créer une collection dans votre base de données appelée usercache et enregistrer ces données exactement comme vous les utilisez dans la vie réelle. Il peut donc s'agir d'une simple requête sur un seul champ [id] pour récupérer toutes ces données. En plus de cela, la base de données nosql n'a pas

Ainsi, une base de données sql peut-elle interroger un champ Id unique aussi rapidement, sinon plus, que nosql? Oui, mais une base de données SQL peut-elle renvoyer toutes les données dont vous avez besoin en interrogeant une table et un champ? Non, sauf si vous faites quelque chose comme enregistrer les données dans Json dans un champ de texte de grande taille. Mais à présent, ces données ne peuvent plus être interrogées pour une utilisation future éventuelle.

— Steffan Perry
source