Nettoyage de base de donnée

[keke]

des outils sont là pour simuler 800 000 clients en même temps :
OpenSTA par exemple.

[phenix]

J'aime beaucoup les réflexions de Roworll, je pense plus ou moins pareil (même si j'applique pas toujours :mauvais
Pour avoir justement eu des problèmes de performances (sur un très faible nombre d'enregistrement en plus) je peux dire que les index sa change la vie... Parfois j'index même des tables entières car je sais qu'il va y avoir beaucoup de requête sur tout les les champs de la table.

Question HS: c'est quoi un verrou :heuuu:

[Roworll]

Les index doivent être choisis avec soins.
Plus tu as d'index, plus une mise à jour dans ta table prendra du temps si elle est liée à un index.
Les INSERT et les DELETE modifient également les index qui doivent rester à jour.
Les UPDATE ne modifie que les index référençant la/les colonnes modifiées.
Donc, si tu as une table à 10 colonnes avec un index sur chaque colonne, je te laisse imaginer le massacre à chaque modification.

Ensuite, les verrous sont des systèmes propres aux BDD pour garantir l'intégrité des données.

MySQL dans sa version classique (MyIsam) InnoDB utilise un verrouillage par table.
En gros, si quelqu'un modifie ou ajoute une information dans une table, personne ne peux ajouter/modifier (et même parfois lire) les informations tant que l'opération n'est pas terminée.

En cas de charge, on peut arriver rapidement à des problèmes de verrouillage (LOCK) qui, s'empilant les uns sur les autres, vont plomber l'application et le serveur.

InnoDB fonctionne avec un système de verrou par ligne. Seule la ligne modifiée est verrouillée/bloquée. C'est moins restrictifs qu'un système de verrou par table mais demande plus de ressources.

Pour en savoir plus sur le sujet, je te conseille de jeter un oeil au modèle de gestion des verrous et des transactions d'InnoDB.

[phenix]

Les index doivent être choisis avec soins.
Plus tu as d'index, plus une mise à jour dans ta table prendra du temps si elle est liée à un index.
Les INSERT et les DELETE modifient également les index qui doivent rester à jour.
Les UPDATE ne modifie que les index référençant la/les colonnes modifiées.
Donc, si tu as une table à 10 colonnes avec un index sur chaque colonne, je te laisse imaginer le massacre à chaque modification.

Je m'en doutais un peu, les tables que j'ai complètement indexé ne dépasse pas 3 champs. C'est principalement des tables de lien style:
id
id_joueur
id_objet

Je me coucherais moins con ce soir. Mais, on a aucun contrôle sur les verrous ?

[keke]

pom pom pom ...

http://dev.mysql.com/doc/refman/5.0/fr/i...model.html

... pom pom pom

[Roworll]

En fonction de ton moteur de BDD, tu as un contrôle plus ou moins poussé sur les verrous.
Tu peux par exemple spécifier dans une transaction que tu acceptes/refuses que les données non validées (uncommited) soient lues par une requête concurrente.

Chaque moteur de BDD possède son propre système mais en général ils font référence au TRANSACTION ISOLATION LEVEL.

Je prends un exemple pour t'expliquer l'impact de ce système.

Supposons que ton système utilise un CRON pour mettre à jour régulièrement le niveau de ressource des joueurs.
Ce processus travaillant sur de gros volumes, il peut être relativement lent (disons 30 secondes).
Pendant qu'il s'exécute, un joueur souhaite lancer une construction.

- Lorsque le joueur accède à sa page, on peut se permettre de le laisser lire des données "sales". Peu importe si la quantité de ressources qu'il voit n'est pas tout a fait exacte. c'est juste une consultation.
- Lorsque le joueur lance la construction, il est hors de question de se baser sur des valeurs non valides.
On doit attendre que la MAJ des ressources soit terminée avant de démarrer le processus de vérification/validation de la construction.

L'utilisation de transaction et de clauses particulière dans tes SELECT te permet de maîtriser ces problèmes de cohérence et même d'éviter des bugs parfois bien mystérieux.

Encore une fois, je te conseille fortement de te lancer dans la lecture des système de verrous/transaction supportés par le moteur de BDD que tu utilises pour mieux appréhender le problème.