+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : MYSQL: une date comme primary key pour un log journalier ? (/showthread.php?tid=5261)
Pages :
1
2
RE: MYSQL: une date comme primary key pour un log journalier ? - Roworll - 11-03-2011
(10-03-2011, 08:45 PM)oxman a écrit : Et donc pendant que tu y es Roworll pourquoi mettre un index sur le jour qui ne va contenir que 31 valeur ?
Essaye donc de mettre aucun index que l'on rigole :p
3 index pourquoi ? Ca mange pas de pain et donne bien plus de flexibilité
Si tu mets 1 index sur les 3, tu es obligé d'interroger dans l'ordre des index, par exemple tu ne peux pas interroger que le jour sans l'année et le mois.
Tu vas me dire à quoi ça servirait ? Bah je sais pas un jour tu auras peut-être besoin d'interroger tous les week-end pour analyser quelque chose.
Et si tu mets un format ODBC canonique comme le suggère Roworll même problème
Ah oui, chui con. t'es un expert en BDD... Un index sur l'année ? Excellente idée.
Au 1er janvier 2011, supposons 1000 joueurs à 2 lignes de log/jour/joueur. En un an ça fait 730000 ligne de log dans la table à laquelle je rajoute 730000 ligne d'index sur l'année pointant uniquement vers 2011. Efficace, vraiment... Un index de taille conséquente qui ne sera jamais utilisé.
Plus sérieusement, la cardinalité d'un index est quelque chose d'important pour définir son efficacité au même prix que la distribution des données dans cet index. Un index inadapté ne sera qu'un poids mort qui prendra de la place et du temps lors des insert/update.
Deux articles trouvés rapidement sur MySQL
http://webmonkeyuk.wordpress.com/2010/09/27/what-makes-a-good-mysql-index-part-2-cardinality/
http://www.mysqlperformanceblog.com/2009/10/16/how-not-to-find-unused-indexes/
Rajoute le cout d'un index scan + RID lookup et il apparaitra qu'il est souvent plus intéressant de faire un bon table scan qu'un mauvais index scan (ce qui montre au passage l'importance des statistiques sur les index)
Pour l'index à construire, j'ai commencé par dire "Ça dépends de la manière dont tu veux traiter tes données." Foutre des index sur tout parce que c'est flexible et que ça ne mange pas de pain, c'est absurde.
Bref, avant de choisir les index et d'en coller n'importe comment, il faut analyser les besoins.
RE: MYSQL: une date comme primary key pour un log journalier ? - srm - 11-03-2011
Non mais je suis au courant de tout ça, essaye de faire des requêtes sur tes tables de ce type sans index, tu verras le résultat
Il n'y aura en effet aucun intérêt à utiliser l'index année si tu l'utilises seul, mais si tu l'utilises avec le jour, ou le mois, ou les deux, là ça devient bien plus utile :p
RE: MYSQL: une date comme primary key pour un log journalier ? - Roworll - 11-03-2011
(11-03-2011, 12:07 AM)oxman a écrit : Non mais je suis au courant de tout ça, essaye de faire des requêtes sur tes tables de ce type sans index, tu verras le résultat
Stop la mauvaise foi : je n'ai jamais dit qu'il ne fallait pas mettre d'index, Juste qu'il fallait mettre des index pertinents.
(11-03-2011, 12:07 AM)oxman a écrit : Il n'y aura en effet aucun intérêt à utiliser l'index année si tu l'utilises seul, mais si tu l'utilises avec le jour, ou le mois, ou les deux, là ça devient bien plus utile :p
Oui mais uniquement si tu l'utilise en combinaison avec des recherches précises sur les valeurs des autres index. Par exemple
Code :
EXPLAIN SELECT * FROM logfile WHERE jour = 21 and mois=08 and annee=2011
------
possible_keys: jour,mois,annee
keys: jour,mois,annee
Using intersect(mois,jour,annee); Using where
EXPLAIN SELECT * FROM logfile WHERE jour BETWEEN 21 and 23 and mois=08 and annee=2011
-------
possible_keys: jour,mois,annee
Key: mois
Extra: Using where
EXPLAIN SELECT * FROM logfile WHERE mois=08 and annee=2011
-------
possible_keys: mois,annee
Key: mois
Extra: Using whereA part dans le premier exemple, ou est l'intérêt de l'index sur l'année ?
PS
c'est d'ailleurs assez amusant de voir comment sans maintenance effective, MySQL se plante sur les cardinalités ce qui pourrait amener à des plans de requête foireux.
Dans une table de 150K enregistrements de date allant de 2011 à 2013 (celle qui m'a servi pour les tests) il me renvoie les cardinalités suivantes sur les index:
jour:210
mois:82
année:7
RE: MYSQL: une date comme primary key pour un log journalier ? - php_addict - 29-03-2011
je me pose une dernière petite question, qui va peut être vous paraitre idiote.
mon système de log est en place, et il s'agit surtout pour être visible dans la partie admin, c'est donc un log journalier
est t il judicieux de mettre en place un système de cache afin de ne pas devoir réinterroger systématiquement la base de donnée quand on visualise le log. un cache en fichier au format JSON par exemple
apres je me dis que meme si une partie dure 3ans, ca ne fait que 3*365 rows à sortir de la base de donnée, c'est pas enorme non ?
RE: MYSQL: une date comme primary key pour un log journalier ? - Myrina - 29-03-2011
C'est à toi de répondre à cette question.
Car oui, un système de cache est toujours bien; maintenant, à chaque fois que tu vas enregistrer un log, il faudra que tu détruises et reconstruise ton cache.
Donc c'est à toi de déterminer son utilité selon que les informations en cache sont plus lues ou plus mises à jour.
RE: MYSQL: une date comme primary key pour un log journalier ? - niahoo - 29-03-2011
Ben tu vas pas regarder ton log toutes les secondes en boucle pendant un an. Tu vas le regarder genre 3fois par jour, et en enregistrer un une seule fois par jour, ce qui est minime.
Donc,systeme de cache totalement inutile mais également coût insignifiant en performances pour le reconstruire.
En as tu vraiment besoin ?
RE: MYSQL: une date comme primary key pour un log journalier ? - php_addict - 29-03-2011
oui je me prends la tête pour rien, c'est nul de mettre si peut de données en cache par rapport au temps que ca va me prendre de mettre le systeme de cache en place...