J'ai un site à forte consultation avec un serveur MySQL 5.0.38.
J'ai quelques problèmes sur de grosses tables.
Par exemple, mes session sont stockées en base dans une table session.
Je souhaite garder les sessions pendant un mois. Cependant ces tables ont vite fait de prendre de l'embonpoint et atteignent souvent quelques millions d'enregistrements.
Evidemment, ce n'est pas vraiment optimum quand il faut rechercher une session sur chaque page php affichée.
Pour cela, j'ai fait un script qui tourne une fois par jour et qui vide les sessions expirées, soit celle qui ont plus d'un mois.
Le problème est le suivant, sur 300 000 enregistrements, cette requête prend déjà 3 minutes!!! Ok, les sessions contiennent beaucoup de variables, mais c'est quand même énorme.
J'utilise une table InnoDB, et le problème, c'est que cette requête bloque les accès en lecture sur la table. Evidemment, car il parait logique que le delete doit d'abord intervenir sur la table complète avant une quelconque lecture.
J'aimerais savoir s'il y a un moyen pour éviter cette concurrence et que les lectures soient possible en concurrence avec les delete.
D'autre part, j'aimerais savoir s'il n'y a pas une architecture possible afin de réduire la taille de la table.
J'ai pensé par exemple, à utiliser 2 tables, une sur laquelle il n'y aurait que 20% des enregistrements, et une autre qui serve d'archive et qui sert pour 80% des autres sessions. Ainsi, les sessions les plus utilisées seront dans la petite base, et les accès seront plus rapides.
Est-ce une bonne solution?
Sinon, autre cas, est-il plus judicieux de mettre par exemple le jour (par exemple 070726) dans une autre colonne de ma table sessions avec un index dessus, et de chercher d'abord parmi les sessions du jour, puis, s'il ne trouve rien, parmi les autres jours?
J'ai également pensé au partitionnement des tables mais je n'ai pas la bonne version de MySQL. Il semble qu'il faille avoir la version 5.1 qui n'est pas encore en version stable.
Pour finir, j'ai un autre problème du même ordre. En fait, pour toutes mes tables un peu grosses (+ 1 000 000 d'enregistrements - InnoDB), j'ai le même problème sur les requêtes de type ALTER TABLE, DELETE, UPDATE et sur l'optimisation des tables. A chaque fois, ça prend pas mal de temps (quelques minutes), et ça bloque tous les accès en lecture à ces tables.
Savez-vous dans quelle direction je dois chercher?
Merci!
J'ai quelques problèmes sur de grosses tables.
Par exemple, mes session sont stockées en base dans une table session.
Je souhaite garder les sessions pendant un mois. Cependant ces tables ont vite fait de prendre de l'embonpoint et atteignent souvent quelques millions d'enregistrements.
Evidemment, ce n'est pas vraiment optimum quand il faut rechercher une session sur chaque page php affichée.
Pour cela, j'ai fait un script qui tourne une fois par jour et qui vide les sessions expirées, soit celle qui ont plus d'un mois.
Bloc de code:
$sql = "DELETE
FROM sessions
WHERE expiry < '".mktime()."'";Le problème est le suivant, sur 300 000 enregistrements, cette requête prend déjà 3 minutes!!! Ok, les sessions contiennent beaucoup de variables, mais c'est quand même énorme.
J'utilise une table InnoDB, et le problème, c'est que cette requête bloque les accès en lecture sur la table. Evidemment, car il parait logique que le delete doit d'abord intervenir sur la table complète avant une quelconque lecture.
J'aimerais savoir s'il y a un moyen pour éviter cette concurrence et que les lectures soient possible en concurrence avec les delete.
D'autre part, j'aimerais savoir s'il n'y a pas une architecture possible afin de réduire la taille de la table.
J'ai pensé par exemple, à utiliser 2 tables, une sur laquelle il n'y aurait que 20% des enregistrements, et une autre qui serve d'archive et qui sert pour 80% des autres sessions. Ainsi, les sessions les plus utilisées seront dans la petite base, et les accès seront plus rapides.
Est-ce une bonne solution?
Sinon, autre cas, est-il plus judicieux de mettre par exemple le jour (par exemple 070726) dans une autre colonne de ma table sessions avec un index dessus, et de chercher d'abord parmi les sessions du jour, puis, s'il ne trouve rien, parmi les autres jours?
J'ai également pensé au partitionnement des tables mais je n'ai pas la bonne version de MySQL. Il semble qu'il faille avoir la version 5.1 qui n'est pas encore en version stable.
Pour finir, j'ai un autre problème du même ordre. En fait, pour toutes mes tables un peu grosses (+ 1 000 000 d'enregistrements - InnoDB), j'ai le même problème sur les requêtes de type ALTER TABLE, DELETE, UPDATE et sur l'optimisation des tables. A chaque fois, ça prend pas mal de temps (quelques minutes), et ça bloque tous les accès en lecture à ces tables.
Savez-vous dans quelle direction je dois chercher?
Merci!
pourquoi n'utilises tu pas des cookies chez les visiteurs plutôt qu'une table géante ? ça règlerait tout ces problèmes non ??
