SQL versus noSQL (vitesse)
Lorsque les gens comparent SQL et noSQL et concluent les avantages et inconvénients de chacun, je n’entends jamais parler de la vitesse.
Effectuer des requêtes SQL n’est-il pas généralement plus rapide que d’exécuter des requêtes noSQL?
Je veux dire, pour moi ce serait une conclusion très évidente, car vous devriez toujours être capable de trouver quelque chose de plus rapidement si vous savez la structure de votre base de données que si vous ne le faites pas.
Mais les gens ne semblent jamais en parler, alors je veux savoir si ma conclusion est bonne ou fausse.
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 fondamentalement que des stockages de clé/valeur persistants (comme Project Voldemort ). Si vos requêtes sont du type "rechercher la valeur d'une clé donnée", un tel système sera plus rapide (ou au moins devrait être) qu'un SGBDR, car il lui suffit de disposer 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 (telle que CouchDB ) . Ces bases de données ne possèdent pas de structure de données prédéfinie . requêtes que vous allez exécuter 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 et accélère vos requêtes, mais pourrait également réduire votre flexibilité en ce qui concerne les requêtes.
Les personnes qui ont tendance à utiliser noSQL l'utilisent spécifiquement parce que cela correspond à leurs cas d'utilisation. Séparés des relations et des contraintes de table SGBDR normales, ainsi que des données ACID-ity, il est très facile de l’exécuter beaucoup plus rapidement.
Pensez à Twitter, qui utilise NoSQL, car un utilisateur ne fait que très peu de choses sur le site, ou un seul - Tweet. Et la concurrence peut être considérée comme inexistante puisque (1) personne ne peut modifier votre Tweet et (2) vous ne serez normalement pas en train de tweeter simultanément à partir de plusieurs appareils.
Comme dirait Einstein, la vitesse est relative.
Si vous devez stocker une application simple maître/détail (comme un panier d'achat), vous devez effectuer plusieurs instructions Insert dans votre application SQL. Vous obtiendrez également un ensemble d'informations Data lorsque vous effectuez une requête pour obtenir l'achat, Si vous utilisez NoSQL et que vous l'utilisez bien, vous disposerez alors de toutes les données d'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 les performances d’une application peuvent être mesurées par le nombre de choses qu’elle doit faire pour répondre à une seule exigence, si vous devez effectuer plusieurs insertions pour enregistrer une commande et qu’il vous suffit d’insérer un simple insertion dans une base de données. comme djondb, les performances seront 10 fois plus rapides dans le monde NoSQL, simplement parce que vous utilisez 10 fois moins d'appels vers la couche base de données, c'est tout.
Pour illustrer mon propos, permettez-moi de relier un exemple que j'ai écrit il y a quelque temps sur les différences entre l'approche des modèles de données NoSQL et SQL: http://djondb.com/blog/?p=4 , je sais que c'est une référence, mais en gros, je l’ai écrit pour répondre à cette question. J’ai trouvé que c’était la question la plus difficile à poser pour un responsable de SGBDR. C’est toujours un bon moyen d’expliquer pourquoi NoSQL est si différent du monde SQL et pourquoi il obtiendra de meilleures performances à tout moment, non pas nous utilisons la technologie "nasa", parce que NoSQL laissera le développeur faire moins ... et obtenir plus, et moins de code = plus de performance.
La réponse est: ça dépend. De manière générale, l'objectif de NoSQL DATABASES (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 pouviez plus redimensionner par les moyens traditionnels (réplication, clustering, partitionnement) et vous avez besoin de quelque chose de plus car vos besoins ne cessent de croître. Ou même si vous parvenez à évoluer, la configuration générale est assez compliquée. Ou vous pouvez redimensionner les lectures, mais pas les é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. N'oubliez pas que les requêtes ne sont qu'un élément du SGBDR.
Plus rapide pour quoi? Mises à jour des données? Inserts? Requêtes à une seule ligne? Des requêtes complexes? La question posée n’a pratiquement aucun sens. Selon ce que vous faites, toute technologie peut être optimale.
En bref: Non, NoSQL n'est pas plus rapide que SQL, et SQL n'est pas plus rapide que NoSQL. Ce sont chacune des technologies différentes adaptées à différents travaux.
Des questions comme la vôtre sont courantes, mais supposent naïvement qu'il existe une bonne réponse. Nous pourrions aussi bien demander à un menuisier si un marteau est préférable à une perceuse ou une scie. Ce sont tous des outils utiles aux fins pour lesquelles ils ont été conçus. Cela n'a aucun sens d'utiliser exclusivement l'un ou l'autre.