SQL versus noSQL (vitesse)
Quand les gens comparent SQL et noSQL, et concluent les avantages et les inconvénients de chacun, ce dont je n'entends jamais parler, c'est la vitesse.
Les requêtes SQL ne sont-elles pas généralement plus rapides que les requêtes noSQL?
Je veux dire, pour moi, ce serait une conclusion vraiment évidente, car vous devriez toujours être capable de trouver quelque chose plus rapidement si vous connaissez {[4] } la structure de votre base de données que si vous ne le faites pas.
Mais les gens ne semblent jamais mentionnez ceci, donc je veux savoir si ma conclusion est bonne ou fausse.
6 réponses
La définition des systèmes noSQL est très large - une base de données qui n'utilise pas SQL / n'est pas un SGBDR. Par conséquent, la réponse à votre question est, en bref: "ça dépend".
Certains systèmes noSQL ne sont essentiellement que des stockages persistants de clés / valeurs (comme Project Voldemort ). Si vos requêtes sont du type "rechercher la valeur d'une clé donnée", un tel système (ou au moins devrait être) plus rapide qu'un SGBDR, car il doit seulement avoir une fonctionnalité beaucoup plus petite définir.
Un autre type populaire de système noSQL est la base de données de documents (comme CouchDB ). Ces bases de données n'ont pas de structure de données prédéfinie. Leur avantage de vitesse repose en grande partie sur la dénormalisation et la création d'une mise en page de données adaptée aux requêtes que vous allez exécuter. Par exemple, pour un blog, vous pouvez enregistrer un article de blog dans un document avec ses commentaires. Cela réduit le besoin de jointures et de recherches, rendant vos requêtes plus rapides, mais cela pourrait également réduire votre flexibilité concernant les requêtes.
Les personnes qui ont tendance à utiliser noSQL l'utilisent spécifiquement parce qu'il correspond à leurs cas d'utilisation. Étant séparé des relations de table et des contraintes normales du SGBDR, ainsi que de l'acidité des données, il est très facile de le faire fonctionner beaucoup plus rapidement.
Considérez Twitter, qui utilise NoSQL parce qu'un utilisateur ne fait que des choses très limitées sur le site, ou un exactement-tweet. Et la concurrence peut être considérée comme inexistante puisque (1) personne d'autre ne peut modifier votre tweet et (2) vous ne le serez normalement pas simultanément tweeter à partir de plusieurs appareils.
Comme dirait Einstein, la vitesse est relative.
Si vous avez besoin de stocker une application simple maître / détail (comme un panier), vous devez faire plusieurs instructions Insert dans votre application SQL, vous obtiendrez également un ensemble d'informations lorsque vous faites une requête pour obtenir l'achat, si vous utilisez NoSQL, et vous l'utilisez bien, alors vous auriez toutes les données pour une seule commande dans un simple "enregistrement" (document si vous utilisez djondb).
Donc, je pense vraiment que la performance d'une application peut être mesurée par le nombre de choses qu'elle doit faire pour atteindre une seule exigence, si vous devez faire plusieurs insertions pour stocker une commande et que vous n'avez besoin que d'une simple insertion dans une base de données comme djondb, la performance sera 10 fois plus rapide dans le monde NoSQL, juste parce que vous utilisez 10 fois moins d'appels à la couche de base de données, c'est tout.
Pour illustrer mon point, permettez-moi de lier un exemple que j'ai écrit il y a quelque temps A propos des différences entre les modèles de données NoSQL et SQL approche: http://djondb.com/blog/?p=4 , je sais que c'est une référence personnelle, mais fondamentalement je l'ai écrit pour répondre à cette question que j'ai trouvé que c'est la question la plus difficile qu'un gars RDBMS pourrait avoir et c'est toujours un bon moyen d'expliquer pourquoi NoSQL est si différent de SQL world, et pourquoi il atteindra de meilleures performances à tout moment, non pas parce que nous utilisons la technologie "nasa", c'est parce que NoSQL laissera le développeur faire moins... et obtenir plus, et moins de code = plus de performances.
La réponse est: cela dépend. D'une manière générale, L'objectif des bases de données NoSQL (pas de "requêtes") est l'évolutivité. Les SGBDR ont généralement des limites strictes à un moment donné (je parle de millons et de millons de lignes) où vous ne pouvez plus évoluer par des moyens traditionnels (réplication, clustering, partitionnement), et vous avez besoin de quelque chose de plus parce que vos besoins ne cessent de croître. Ou même si vous parvenez à évoluer, la configuration globale est assez compliquée. Ou vous pouvez mettre à l'échelle les lectures, mais pas écrire.
Et les requêtes dépendent de l'implémentation particulière de votre serveur, du type de requête que vous effectuez, des colonnes de la table, etc... rappelez-vous que les requêtes ne sont qu'une partie du SGBDR.
Plus Rapide pour quoi? Données mises à jour? Des Inserts? Requêtes à une ligne? Des requêtes complexes? La question comme indiqué est pratiquement dénuée de sens. Selon ce que vous faites, toute technologie pourrait être optimale.
En bref: Non, NoSQL n'est pas plus rapide que SQL, et SQL N'est pas plus rapide que NoSQL. Ils sont chacun des technologies différentes adaptées à différents travaux.
Des Questions comme la vôtre sont communes, mais supposons naïvement qu'il y a une bonne réponse. Nous pourrions aussi bien demander à un charpentier si un marteau est meilleur que une perceuse ou une scie. Ce sont tous des outils, utiles aux fins pour lesquelles ils ont été conçus. Il ne fait aucun sens d'utiliser l'un ou l'autre exclusivement.
Le temps de requête de la base de données relationnelle comme SQL pour les données de 1000 personnes est de 2000 ms et la base de données graphique comme neo4j est 2ms .si vous crate plus noeud 1000000 vitesse stable 2 ms