Performance: Besoin de lire depuis LONGTEXT

Question

Je construis une webapp de type CMS qui permet aux utilisateurs d'entrer des blocs HTML de taille arbitraire. Ces blocs sont entrés par l'utilisateur dans sa zone d'administration et insérés dans son modèle de choix lors de la livraison d'une page.

Je suppose qu'un utilisateur ne va pas ajouter plus de 50-100 blocs et je ne compterai pas bientôt plus de 1000 utilisateurs. J'avais prévu d'utiliser le type LONGTEXT de mySQL pour les stocker mais je me demande si le stockage des fichiers dans un répertoire sera plus performant car le système d'exploitation Linux les mettra en cache? Étant donné que je construis au maximum (1000 * 100) blocs de texte, y a-t-il des soucis de performances raisonnables avec mySQL?

Évidemment, je mettrai en cache le code HTML avant la livraison, donc je ne lirai pas ces blocs à chaque livraison - les lectures ne se produiront que si quelqu'un met à jour/crée un nouveau contenu. Je pourrais utiliser l'implémentation memcached/autre cache/noSQL ou un autre mécanisme de stockage, mais je me concentre sur la simplicité et la rapidité de la livraison. Je ne veux pas introduire d'autres choses que je n'ai pas expérimentées à moins qu'il y ait une inquiétude de performance significative.

Answer 1

Je vous conseille d'utiliser un fichier plat plutôt que Mysql pour stocker ce type de données.
Html est plus un "fichier" qu'une "information de valeur" donc il ne doit pas être dans une base de données.
De plus, vous aurez certainement de meilleures performances.

Vous pouvez également lire this post.

Answer 2

Les blocs de contenu HTML la seule chose que vous enregistrez? Si oui, un fichier peut être le plus facile. Toutefois, il semble probable que vous souhaitiez enregistrer d'autres bits d'information avec le code HTML et pouvoir interroger en fonction de ces bits de données. Par exemple: date de création, date de dernière modification, nom du bloc, utilisateur (s) ayant édité le bloc.

Si c'est le cas, une base de données peut être la meilleure solution. Puisque vous ne vous attendez pas à avoir beaucoup d'utilisateurs (du moins pas une première), je chercherais la solution la plus rapide/flexible pour programmer et mettre l'accent sur les performances et la mise en cache après que votre site Web ait commencé à grossir.