performances mysql (10 a 100 millions de rows)

[killy-kun]

je suis actuellement en train de developper un outil d'analyse de logs firewall
tous les evenements sont enregistres dans une database

concernant les performances je me pose de tres nombreuses questions dont en voici quelques unes :

(ps : la performance en insertion a ici peu d'importance)

- que choisir entre myasm et innodb pour accroitre les performances des select ?

- quelle est la capacite maximum que pourrait contenir la database, a savoir qu'il faudrait dans le cas present que cela puisse aller jusqu'a 50 ou 100 millions d'enregistrements

- j'ai lu sur un site qu'il etait deconseille de mettre un index lorsque la selection d'une valeur de cette index renvoyait plus de 5 % du total des enregistrements .... or, en testant il s'avere que c'est bien plus rapide avec les index ... plausible ?

- quelqu'un a t il deja developpe un tel outil ? si oui je lui poserais bien quelques questions quant aux moyens qu'il a utilise pour optimiser les performances ... et peut etre demander s'il a des chiffres quand a la performance de son outil pour que je me fasse une idee

- ici la taille de stockage m'importe peu compare aux performances ... ainsi, je me demande s'il s'avere veredique que le filtrage de champs de taille fixe (CHAR) est plus rapide que celui de champs de taille variable (VARCHAR) ...

- est il possilbe de creer un index sur les 2 premiers caracteres d'un champ sql de type TIME ?

- lors de mes cours de sgbd, j'ai vu comment on optimisait les requetes en eleminant les champs inutiles le plus tot possible, en projettant le plus tot possible, etc, en shematisant la requete par un arbre binaire ... mais je n'ai pas vu d'application en pratique.
ainsi je me demande s'il s'agit d'une solution applicable, et dans ce cas, est-ce qu'elle correspondrait a des requetes imbriques ??
(ca m'etonnerait quant meme, car s'il faut faire une requete imbriquee a chaque noeud ca peut rapidement en faire 10 ou 20 en tout pour une requete ma fois pas trop compliquee, et je doute que ca soit bon pour les performances ....)

merci d'avance pour vos precieuses reponses

[ren0]

Bonjour,

- que choisir entre myasm et innodb pour accroitre les performances des select ?

MyIsam est plus performant sur les opérations de lecture.

- quelle est la capacite maximum que pourrait contenir la database, a savoir qu'il faudrait dans le cas present que cela puisse aller jusqu'a 50 ou 100 millions d'enregistrements

La question du nombre d'enregistrement importe peu. Au niveau du volume, j'ai déjà vu des bases de plusieurs dizaines (jusqu'à 60 Go) de Go en MyIsam et déjà lu des posts avec des bases de plus de 100 Go.
Donc pas de soucis niveau volume d'enregistrement.

- j'ai lu sur un site qu'il etait deconseille de mettre un index lorsque la selection d'une valeur de cette index renvoyait plus de 5 % du total des enregistrements .... or, en testant il s'avere que c'est bien plus rapide avec les index ... plausible ?

Tout à fait... Tout dépend de la volumétrie, de la manière dont sont construit les index, de leur niveau de fragmentation et surement de beaucoup d'autres choses qui me dépassent...
L'idéal, comme tu l'as fait, est de comparer les résultat obtenus et d'opter pour le plus performant. Dans certains cas, les normes admises s'avèrent donner le plus mauvais résultat.

- ici la taille de stockage m'importe peu compare aux performances ... ainsi, je me demande s'il s'avere veredique que le filtrage de champs de taille fixe (CHAR) est plus rapide que celui de champs de taille variable (VARCHAR) ...

La question se mesure en terme de performance en select.

En fait sur une lecture sur un champ non indexé, il va se produire de nombreuses lectures sur le disque pour effectuer le balayage de la table.
- Si tu as utilisé des CHAR, les enregistrements remontés seront tous de taille fixe (c'est la particularité du CHAR => taille fixe en BD) => meilleure performance en lecture car le SGBD sait comment lire les enrgistrements aisément.
- Si tu as opté pour du VARCHAR, tes enreg n'ont pas une taille fixe, cependant, tu as de fortes chances de pouvoir lire plus d'enreg à chaque lecture sur disque (car les VARCHAR n'utilise que l'espace nécessaire à stocker les caractères effectif) => meilleure perf car plus d'enreg lu à chaque lecture sur disque.

Aprés c'est à toi de voir, mais, il est communément admis que le VARCHAR est plus performant car le gain de volume engendré par le VARCHAR engendre un gain en performance supplémentaire

- est il possilbe de creer un index sur les 2 premiers caracteres d'un champ sql de type TIME ?

Code :

1
2
3
4
5
6
       CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name
       [USING index_type]
       ON tbl_name (index_col_name,...)
 
       index_col_name:
       col_name [(length)] [ASC | DESC]

Tu as length donc normalement oui. J'ai déjà fait ça sur du texte jamais sur une date alors je ne mets pas ma main à couper non plus...

- lors de mes cours de sgbd, j'ai vu comment on optimisait les requetes en eleminant les champs inutiles le plus tot possible, en projettant le plus tot possible, etc, en shematisant la requete par un arbre binaire ... mais je n'ai pas vu d'application en pratique.
ainsi je me demande s'il s'agit d'une solution applicable, et dans ce cas, est-ce qu'elle correspondrait a des requetes imbriques ??
(ca m'etonnerait quant meme, car s'il faut faire une requete imbriquee a chaque noeud ca peut rapidement en faire 10 ou 20 en tout pour une requete ma fois pas trop compliquee, et je doute que ca soit bon pour les performances ....)

Utilise la commande EXPLAIN et lis les tutos sur developpez.com qui sont relativement complet


HTH,