SQL contre noSQL (vitesse)

Question

Lorsque les gens comparent SQL et noSQL, et en concluent les avantages et les inconvénients de chacun, ce dont je n'entends jamais parler, c'est de la vitesse.

L'exécution de requêtes SQL n'est-elle pas généralement plus rapide que d'effectuer des requêtes noSQL ?

Je veux dire, pour moi, ce serait une conclusion vraiment évidente, parce que vous devriez toujours être en mesure de trouver quelque chose plus rapidement si vous connaître la structure de votre base de données que si vous ne le faites pas.

Mais les gens ne semblent jamais le mentionner, alors je veux savoir si ma conclusion est bonne ou mauvaise.

Answer 1

Les personnes qui ont tendance à utiliser les systèmes noSQL les utilisent spécifiquement parce qu'ils correspondent à leurs cas d'utilisation. Étant donné qu'il n'y a pas de relations et de contraintes normales entre les tables d'un SGBDR, ni d'ACID-ité des données, il est très facile de le faire fonctionner beaucoup plus rapidement.

Prenons l'exemple de Twitter, qui utilise NoSQL parce qu'un utilisateur ne fait que des choses très limitées sur le site, ou une seule exactement - un 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 serez normalement pas en train de tweeter simultanément depuis plusieurs appareils.

Answer 2

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 : "cela dépend".

Certains systèmes noSQL sont essentiellement des stockages persistants de clés/valeurs (comme le Projet Voldemort ). Si vos requêtes sont du type "rechercher la valeur d'une clé donnée", un tel système permettra (ou du moins devrait être ) plus rapide qu'un SGBDR, parce qu'il n'a besoin que d'un ensemble de fonctionnalités beaucoup plus réduit.

Un autre type populaire de système noSQL est la base de données de documents (comme la base de données d'images). CouchDB ). Ces bases de données n'ont pas de structure de données prédéfinie. Leur avantage en termes de vitesse repose en grande partie sur la dénormalisation et la création d'une structure de données adaptée aux requêtes que vous exécuterez dessus. 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, ce qui accélère les requêtes, mais peut également réduire la flexibilité des requêtes.

Answer 3

Comme le dirait Einstein, la vitesse est relative.

Si vous avez besoin de stocker une application simple maître/détail (comme un panier d'achat), vous devrez faire plusieurs déclarations d'insertion dans votre application SQL, et vous obtiendrez également un ensemble de données d'information lorsque vous ferez une requête pour obtenir l'achat, si vous utilisez NoSQL, et que vous l'utilisez bien, alors vous aurez toutes les données pour une seule commande dans un simple "enregistrement" (document si vous utilisez les termes des bases de données NoSQL comme 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 répondre à 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, alors la performance sera 10x 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 propos, je vais vous présenter un exemple que j'ai écrit il y a quelque temps sur les différences entre les modèles de données NoSQL et SQL : https://web.archive.org/web/20160510045647/http://djondb.com/blog/nosql-masterdetail-sample/ Je sais qu'il s'agit d'une référence personnelle, mais je l'ai écrit pour répondre à cette question, qui est la plus difficile pour un spécialiste des SGBDR. C'est toujours un bon moyen d'expliquer pourquoi NoSQL est si différent du monde SQL et pourquoi les performances seront meilleures à tout moment, non pas parce que nous utilisons la technologie de la NASA, mais parce que NoSQL permet au développeur d'en faire moins... et d'en obtenir plus, et moins de code = meilleures performances.

Answer 4

La réponse est : cela dépend. D'une manière générale, l'objectif des BASES DE DONNEES NoSQL (pas de "requêtes") est l'évolutivité. Les SGBDR ont généralement des limites strictes à un moment donné (je parle de millions et de millions de lignes) où vous ne pouvez plus évoluer par les 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 bien, même si vous parvenez à faire évoluer votre système, la configuration globale est assez compliquée. Ou vous pouvez faire évoluer les lectures, mais pas les écritures.

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... n'oubliez pas que les requêtes ne sont qu'une partie du SGBDR.

Answer 5

Le temps d'interrogation d'une base de données relationnelle comme SQL pour des données concernant 1000 personnes est de 2000 ms et une base de données graphique comme neo4j est de 2 ms. Si vous créez plus de 1000000 noeuds, la vitesse est stable à 2 ms.