Lecture/Ecriture fichier texte vs MySQL ?

Lecture/Ecriture fichier texte vs MySQL ? - PHP - Programmation

Marsh Posté le 21-05-2007 à 14:22:06    

Salut à tous :hello:,
 
J'me posais une petite question ...
 
Sur un site très fréquenté, avec des dizaines voire des centaines de requêtes MySQL à la seconde, vaut-il mieux stocker des infos dans un fichier texte ou avec MySQL ?
 
Je m'explique :
Il s'agit d'un affichage de statistiques très simples ... Nombres de membres, nombre de messages, etc.
 
En version fichier texte, ce sont donc quelques nombres qui sont stockés, pas de texte à proprement dit.
En version MySQL, pareil, avec les champs correspondants.
 
Bref, je me demandais quelle solution était la plus performante :
- Ecrire dans un fichier .txt, et le lire par la suite.
- Ecrire dans MySQL (en sachant qu'il y a bcp de requêtes à la seconde et que ce fichier est mis à jour très très fréquemment, genre toutes les 10s).
 
J'ai peur que la solution du fichier texte ne soit pas très performant en terme de rapidité d'éxecution ... Le fopen est pas un peu lourd ? Ca prend pas du temps ?
 
J'espère que vous aurez saisi ce que j'ai voulu dire :D
 
A bientot et merci ;) :jap:


---------------
En attente d'anonymat.
Reply

Marsh Posté le 21-05-2007 à 14:22:06   

Reply

Marsh Posté le 21-05-2007 à 15:01:18    

Absolument MySQL! Il y a beaucoup d' ans de lui optimisaient pour la vitesse. La recherche à MySQL très rapide. Le changement de la quantité de champs des fichiers pas simple.

Message cité 1 fois
Message édité par andr_9999 le 21-05-2007 à 15:02:05
Reply

Marsh Posté le 21-05-2007 à 15:02:00    

'vache, je comprends rien [:joce]


---------------
En attente d'anonymat.
Reply

Marsh Posté le 21-05-2007 à 15:14:30    

+1
edit: mais je serais assez pro BDD si ton contenu change vraiment toutes les 10 secondes.
Après quel est vraiment l'interet d'actualiser toutes les 10 secondes?
N'y a-t-il pas des parties dont tu pourrais générer directement l'html dans des fichiers ( inclus directement ensuite) et rafraichir ces fichiers toutes les heures?


Message édité par anapajari le 21-05-2007 à 15:15:55
Reply

Marsh Posté le 22-05-2007 à 03:01:53    

T'as quoi comme serveur franchement ? Un bi opteron 8 giga de RAM ?
 
Mais oui faut cacher fichier.
 

Reply

Marsh Posté le 22-05-2007 à 08:54:36    

andr_9999 a écrit :

Absolument MySQL! Il y a beaucoup d' ans de lui optimisaient pour la vitesse. La recherche à MySQL très rapide. Le changement de la quantité de champs des fichiers pas simple.


ouais, c'est pas faux.
 
je serais plus partant pour mysql, parce qu'écrire dans un fichier est une opération un peu plus longue qu'écrire dans une table...

Reply

Marsh Posté le 22-05-2007 à 16:29:32    

NewsletTux a écrit :

ouais, c'est pas faux.

 

je serais plus partant pour mysql, parce qu'écrire dans un fichier est une opération un peu plus longue qu'écrire dans une table...

 

Tout depend du reseau en fait ...

 

Le compromis est simple : si la donnee doit etre protegee (ou appartient a un ensemble protege) utiliser SQL sinon si la donnee n'a aucune importance alors passer en fichier sur localhost et rafraichir sur un intervalle de tps.

 

Ex de donnee sans importance : un template, un <script>, une image donc la vue en general.

 

Par contre le fait de vouloir "copier" le comportement SQL en fichier, je suis relativement contre puisque ces gestionnaires sont les meilleurs candidats dans ce type de probleme.

 

Meilleure solution pour l ami du dessus c'est un cache html ET de penser a normaliser la DB.

 


Prout


Message édité par supermofo le 22-05-2007 à 16:40:25
Reply

Marsh Posté le 22-05-2007 à 18:20:57    

oui, mais il me semble au point de vue accès concurrentiels que mysql est une technique qu'il vaut mieux privilégier par rapport au fichier ... Maintenant, je suis ok sur ce que tu dis. Et puis ça dépend de la fréquence de rafraichissement qui est indirectement liée au nombre de visiteurs simultanés.

Reply

Marsh Posté le 22-05-2007 à 21:22:03    

Acces concurrentiel en ecriture tu veux dire ? Ya aussi des semaphores pour php et le fopen : flock().
 
Sinon pour la lecture, on ne peut pas faire mieux que ce l'OS nous offre n'est ce pas ?
A ce niveau la d'optimisation moi j'ai penche pour OpenBSD en premier puis FreeBSD pour probleme de raid, puis je suis reste sur dernier.
 
Je suis assez frustre de ne voir qu il ya si peu de reponse pour un topic si interessant !

Reply

Marsh Posté le 23-05-2007 à 09:14:40    

oui, en effet, mais la réflexion est plutôt de savoir si l'opération { file lock, file write, file unlock } est plus rapide et non bloquante que l'opération { sql update } par rapport à l'accès concurrentiel.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed