NoSQL vs SQL : Comprendre la différence de performance
lundi 21 mars 2016 à 18:35« Ainsi, tandis que le SQL a des performances acceptables (mais pas idéale) dans toutes les situations, la base NoSQL, elle, est imaginée pour exceller dans la réponse à un besoin spécifique. En dehors de ce besoin de prédilection, elle aura des performances en dessous d'une base SQL. »
C’est exactement le problème que j’avais avec Blogotext quand je l’avais repris : il fonctionnait à l’époque avec des fichiers texte, comme PluXML.
L’organisation des fichiers dans PluXML est mieux faite que dans le Blogotext de l’époque : PluXML range les commentaires par article, et Blogotext le faisait par date. Or c’est quoi qu’on fait le plus souvent ? On associe les commentaires aux articles. La liste des commentaires par date était super rapide, mais l’affichage d’un article était super lent (le temps de lire les milliers de fichiers de commentaires pour voir à quel article ils étaient associés).
Blogotext devenait très lent avec un grand nombre de commentaires (c’est à ce moment là que je suis passé à du SQL).
En revanche, un blog avec un millier d’articles et zéro commentaires restait super rapide : pas besoin de lire tous les articles pour afficher la page d’accueil, simplement récupérer les 10 derniers fichiers XML dans la base. C’est typiquement le blog de Sebsauvage, sous Blogotext 1.x en fichiers textes sans commentaires : c’est super rapide.
J’ai un article (jamais publié) à ce sujet, où je parle de ça. La conclusion est la même que l’article ici : les deux ont des points forts et des points faibles, mais il faut vraiment savoir où on veut aller avec son programme, pour pouvoir faire son choix correctement.
Si vous avez des données qui s’associent ensemble (articles ⇔ commentaires), préférez du SQL : tout aura des performances plutôt bonnes.
Si vous avez des données simples (une seule liste de liens, d’articles, de fichiers…), prenez du NoSQL, comme un fichiers texte : aucun tri à faire, ça sera rapide.
Dans tous les cas, il est sûr que plus la base de données prend du volume, plus ça sera lent (et ça, c’est une question d’optimisation SQL, avec choix des index, de la gestion mémoire et un système de cache qui feront la différence).
— (permalink)
C’est exactement le problème que j’avais avec Blogotext quand je l’avais repris : il fonctionnait à l’époque avec des fichiers texte, comme PluXML.
L’organisation des fichiers dans PluXML est mieux faite que dans le Blogotext de l’époque : PluXML range les commentaires par article, et Blogotext le faisait par date. Or c’est quoi qu’on fait le plus souvent ? On associe les commentaires aux articles. La liste des commentaires par date était super rapide, mais l’affichage d’un article était super lent (le temps de lire les milliers de fichiers de commentaires pour voir à quel article ils étaient associés).
Blogotext devenait très lent avec un grand nombre de commentaires (c’est à ce moment là que je suis passé à du SQL).
En revanche, un blog avec un millier d’articles et zéro commentaires restait super rapide : pas besoin de lire tous les articles pour afficher la page d’accueil, simplement récupérer les 10 derniers fichiers XML dans la base. C’est typiquement le blog de Sebsauvage, sous Blogotext 1.x en fichiers textes sans commentaires : c’est super rapide.
J’ai un article (jamais publié) à ce sujet, où je parle de ça. La conclusion est la même que l’article ici : les deux ont des points forts et des points faibles, mais il faut vraiment savoir où on veut aller avec son programme, pour pouvoir faire son choix correctement.
Si vous avez des données qui s’associent ensemble (articles ⇔ commentaires), préférez du SQL : tout aura des performances plutôt bonnes.
Si vous avez des données simples (une seule liste de liens, d’articles, de fichiers…), prenez du NoSQL, comme un fichiers texte : aucun tri à faire, ça sera rapide.
Dans tous les cas, il est sûr que plus la base de données prend du volume, plus ça sera lent (et ça, c’est une question d’optimisation SQL, avec choix des index, de la gestion mémoire et un système de cache qui feront la différence).
— (permalink)