Reprise du message précédent :

Connexions, pas connections (anglais)
 
Ça veut dire que dans les 5 dernières minutes (enfin le timeout d'HFR, je ne le connais pas), il y a eu 3000 personnes qui ont éffectué au moins 1 requête (à savoir, liste des messages d'un topic, liste des topics d'une catégorie, affichage d'un profil, enfin toute page accessible). Tout ça demande des requêtes au niveau serveur.

C'est un autre problème à mon avis. Un problème de modération et de tenue du forum par ses administrateurs.
 

Moi aussi j'aurai de l'AJAX. Enfin faut déjà que je m'active un peu pour entrer dans le vif du sujet car je suis toujours sur mon framework
 

Non, ça veut dire que 3000 personnes identifiées ont visité le forum dans les dernières X minutes (à voir comment c'est calculé ici).
 
Ou pire: ont posté quelque chose dans les X dernières minutes

A moins qu'il ne fasse une requête avec une condition en plus, du style "AND deletedPost = 0".

 
Ça ne changera rien avec BETWEEN

Ok merci.
 

Bah, à priori, si tu fais un SELECT avec un BETWEEN sur l'identifiant..
edit
Waif en fait t'as raison.

 
ben justement, tu ne sais pas sur quoi le faire ton beetwen

Si je me souviens bien, sur ce topic à une époque ça avait été débattu, et plusieurs membres parlait de mettre un ID à chaque post, en plus de l'ID unique de chaque post.
En gros un compteur, qui se met à jour à chaque insertion d'un nouveau post / suppression de post...
Et donc le between serait là-dessus.

J'avais l'intention de tenir un champ particulier à cet effet.

Avec un trigger qui, lorsqu'on supprime une entrée, recalcule le "NUM" des entrées suivantes. Mais en fait ça va pas, un trigger sur une table ne peut pas faire un update de cette même table

grilled

et sur un topic de 500 000 messages, je supprime le premier message, vous allez mettre a jours 499 999 ligne de la col "num" ?!!!

c'est bien de ça qu'on avait discuté, mais vu le rapport  messages vus / messages supprimés, je crois que le truc en valait la chandelle

(puis alors un massdelete des messages d'un utilisateur, lolilol la base de données)

Un forum, c'est comme la photographie, que des compromis de partout
 

Et c'est comme ça que HFR vole en morceau dès qu'un modo a le doigt un peu lourd sur le massdelete

ce qui n'arrive que très occasionnellement, tout le monde est d'accord

 
le simple fait que ça puisse arriver rend la solution immonde amha.

tu préfère un forum qui rame dès que tu consultes un topic ?

Je préfère un forum qui menace pas de tomber en miettes pour une durée indéterminée au moindre clic d'un modo.

Mauvaise foi
Un mass-delete, ça fera ramer le forum pendant 1 minute max, le temps de mouliner, mais c'est tout

ça dépend. Quand c'est gilou qui clique ça met une partie du forum en carafe pendant 2 jours.

 
Bon, j'ai une vie sociale, moi.
Je vous laisse

À mon avis c'est pas exactement ça qui est utilisé sur HFR ... puisqu'un masse delete pète un topic ... alors qu'avec cette solution, ça rame sur le coup, mais les topics restent fonctionnels ...
 
Bon donc d'après vous faudrait utiliser LIMIT ? J'ai quelques doutes niveau perf quand même, quand je vois le nombre de topic sur HFR qui dépassent les 10000 posts ...

Et ça flingue un topic pendant 2 semaines

Huhu. Si tu réussis à écrire ton trigger correctemement, oui.

 
Je vais simplement passer par une table externe

"simplement".

 
Avec une jointure ça va rouler tout seul, et rapidement vu les index

le plus lourd, c'est pas le select, mais le update de centaine de milliers de "position"

Qui arrivera certainement largement moins souvent que les 10aines de milliers d'affichage que pourra avoir un topic de  1 000 000 de post.

D'autant que si un topic est aussi gros, c'est qu'il doit avoir énormément de visites.

De plus, lorsqu'on regarde un topic, on va principalement sur la dernière page, là où le LIMIT est encore plus violent.

Donc à mon avis le update une fois de temps en temps, sur une table entièrement indexée, ne devrait pas poser de problème.

Et concernant les users qui delete un post, c'est souvent un post qu'ils ont écrit récemment. Je pense qu'un user qui supprime le 3ème post d'un topic de 1 million de post, ça doit pas arriver souvent.

Euh pourquoi tu fous pas le champ position dans la table des posts ?

Non, y suffit de faire l'astuce du LIMIT inversé et c'est instantané pour les pages les + vues au début et à la fin d'un topic (temps de génération maximal au milieu du topic donc mais quand même divisé par 2 par rapport au LIMIT simple). Y a que les bots qui parcourent tout le topic n'importe comment généralement.

Pour le delete, ça se passe à 99% sur la dernière page avant même qu'il y ait d'autres replys derrière en général, donc l'UPDATE est instantané aussi. Et puis y suffit d'interdire le delete au bout de 1 mois par exemple et t'es tranquille.

Y a aussi l'astuce de retenir les ID des posts deletés dans une table à part et de compter combien y en a avant l'ID du BETWEEN selectionné pour savoir de combien décalé sans rien avoir à recalculer.

D'autant plus que MySQL + MyISAM fait toujours pas de row locking si? Donc chaque batch d'update lock toute la table

Non, ça le fait toujours pas

Table lock

 
Non mais InnoDB oui

Oui mais si c'est pour prendre InnoDB, pourquoi ne pas envisager autre chose que MySQL
 
(en attendant Falcon )

1. Je suis au courant, raison pour laquelle j'ai parlé de "MySQL + InnoDB" et non "MySQL"
2. La dernière fois qu'on a parlé des tables InnoDB (ou -- god forbid -- de Postgres), la vaste majorité était de l'avis que les transactions et autres cohérence des données ça n'a aucun intérêt et que le seul truc qui soit important c'est la vitesse des select, donc d'utiliser MyISAM
3. À ma connaissance, MyISAM reste la table par défaut de MySQL

 
Quel rapport entre InnoDB et MySQL ?

 
Hum, avec MyISAM je peux dire au revoir à mes ON DELETE CASCADE ...