Pourquoi NoSQL est-il plus rapide que SQL?

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?

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.

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.

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.

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.

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

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.

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!

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.