JustWriting - Votre blog 100% Markdown (et sans base de données) - Korben
lundi 29 septembre 2014 à 15:10HowTommy, le 29/09/2014 à 15:10
Dommage que Korben parle de ça et pas de Blogotext :(
(Permalink)
Timo > HowTommy, le 29/09/2014 à 15:55
:)
Mais il en parle, un peu~
Par contre, au début j’ai aussi prôné le « noSQL ». Sauf que quand mon blog a atteint les 10k commentaires et 500 articles, j’ai moins rigolé.
Je vous le dis : les PluXML, JustWriting ou encore FlatPress sont rapides comme la lumière avec 1 ou 2 articles (comme le font les sites qui "testent" les logiciels). Mais dès que vous en avez plus d’une centaine et encore plus de commentaires, ils deviennent incroyablement lourds.
Le véritable problème c’est qu’avec les fichiers textes, il n’est pas possible d’avoir ces trois fonctions réunies :
– recherche dans les articles rapide
– liaison articles/commentaires sans ralentir le serveur
– optimiser le stockage
Il y a toujours un truc qui gène :
– Si on mets tous les commentaires d’un article dans le fichier de l’article, alors vous allez en chier pour trier les commentaires (par auteur, par date…)
– Si on met les commentaires d’un côté et les articles de l’autre (c’était le cas de BT-v1), alors la liaison article/commentaire est super lente
– Si on met tout en vrac ou vous faites deux stockages (une pour l’assoc, l’autre pour la recherche), alors il faudra dupliquer des données : titre des articles avec les commentaires, ID des commentaires et des articles, noms de fichiers à rallonge… (c’est ce que fait pluXML).
Les BDD optimisent le stockage tout en offrant des fonctions de tri et de jonction entre les tables (commentaires, articles…) très poussées et rapides. C’est ça le véritable avantage des BDD style *SQL. Si on regarde *SQL comme un vulgaire tableau de données, alors oui, le fichier texte est bien mieux, mais SQL offre bien plus que le stockage.
(Quant au système de Shaarli, si ça marche bien, c’est parce qu’il n’y a pas d’associativité article/commentaire : du coup ça peut être rapide ET efficace niveau place, même si la conversion Base64 (indispensable) + compression (pas forcément indispensable, je pense) représente à lui seul 99% de la charge serveur)
— (permalink)
Pixel Café > HowTommy, le 29/09/2014 à 16:12
Tommy > Je ne sais pas si Korben a rajouté ça par la suite, mais il parle bien de Blogotext en fin d'article.
(Permalink)
Dommage que Korben parle de ça et pas de Blogotext :(
(Permalink)
Timo > HowTommy, le 29/09/2014 à 15:55
:)
Mais il en parle, un peu~
Par contre, au début j’ai aussi prôné le « noSQL ». Sauf que quand mon blog a atteint les 10k commentaires et 500 articles, j’ai moins rigolé.
Je vous le dis : les PluXML, JustWriting ou encore FlatPress sont rapides comme la lumière avec 1 ou 2 articles (comme le font les sites qui "testent" les logiciels). Mais dès que vous en avez plus d’une centaine et encore plus de commentaires, ils deviennent incroyablement lourds.
Le véritable problème c’est qu’avec les fichiers textes, il n’est pas possible d’avoir ces trois fonctions réunies :
– recherche dans les articles rapide
– liaison articles/commentaires sans ralentir le serveur
– optimiser le stockage
Il y a toujours un truc qui gène :
– Si on mets tous les commentaires d’un article dans le fichier de l’article, alors vous allez en chier pour trier les commentaires (par auteur, par date…)
– Si on met les commentaires d’un côté et les articles de l’autre (c’était le cas de BT-v1), alors la liaison article/commentaire est super lente
– Si on met tout en vrac ou vous faites deux stockages (une pour l’assoc, l’autre pour la recherche), alors il faudra dupliquer des données : titre des articles avec les commentaires, ID des commentaires et des articles, noms de fichiers à rallonge… (c’est ce que fait pluXML).
Les BDD optimisent le stockage tout en offrant des fonctions de tri et de jonction entre les tables (commentaires, articles…) très poussées et rapides. C’est ça le véritable avantage des BDD style *SQL. Si on regarde *SQL comme un vulgaire tableau de données, alors oui, le fichier texte est bien mieux, mais SQL offre bien plus que le stockage.
(Quant au système de Shaarli, si ça marche bien, c’est parce qu’il n’y a pas d’associativité article/commentaire : du coup ça peut être rapide ET efficace niveau place, même si la conversion Base64 (indispensable) + compression (pas forcément indispensable, je pense) représente à lui seul 99% de la charge serveur)
— (permalink)
Pixel Café > HowTommy, le 29/09/2014 à 16:12
Tommy > Je ne sais pas si Korben a rajouté ça par la suite, mais il parle bien de Blogotext en fin d'article.
(Permalink)