Performances sur très grosse table

[CinePhil]

Bonjour,
J'ai quelques inquiétudes sur la future utilisation de la base de données que je suis en train de mettre en place.

Plusieurs tables font plusieurs dizaines de millions de lignes.

J'en suis à peu près à la moitié du travail d'importation des données dans le modèle normalisé que j'ai créé. J'ai commencé à faire quelques interrogations et je suis inquiet de la lenteur de requêtes simples par rapport aux futurs traitements statistiques qui devront être faits.

Par exemple, un simple SELECT COUNT(DISTINCT colonne) sur une colonne clé étrangère indexée prend 5 minutes sur une table de 67 millions de lignes.

Est-ce normal ou choquant ?
Y-a t-il moyen de baisser ce temps de réponse ?

Les tables sont en MyIsam (nous n'avons pas besoin de contraintes de clés étrangères car les données ne seront pas modifiées, même si le modèle est normalisé avec des clés étangères).

Pour le moment, je travaille sur un portable à processeur Intel Core duo à 2,20 GHz et 2Go de mémoire.

MySQL est en version 4.1.9-max et installé par EasyPHP sans avoir changé la configuration, à part les timeout.

Le serveur actuel est plus puissant et nous devrions bientôt en avoir un autre. Voici les caractéristiques du serveur actuel :

Caractéristiques du serveur

processeur : XEON 5160 bi-processeur double coeur 3GHz/4MB cache
Mémoire : 8 GB 667 MHz (4x2GB dual rank DIMMs)
Disque Dur : 3 disques durs de 300 GB SAS (10000 rpm)

[gregory.broissard]

faire un count sur un distinct implique des opérations de tri et de suppression de doublons sur l'ensemble des données . Ces opérations sont couteuses pour tout SGBD

Le temps me choque donc pas sur plusieurs dizaines de millions de lignes

[Sivrît]

Envoyé par gregory.broissard

faire un count sur un distinct implique des opérations de tri et de suppression de doublons sur l'ensemble des données . Ces opérations sont couteuses pour tout SGBD

Le temps me choque donc pas sur plusieurs dizaines de millions de lignes

Comme il y a un index sur la colonne ça ne devrait pas être si défavorable que ça puisque tout est déjà trié...

D'un autre côté avec des tables de cette taille toute opération qui concerne toute la table ne sera pas instantanée. Les accès disques seront certainement le facteur limitant alors avec un disque dur anorexique de portable c'est presque un bon temps

Eventuellement il y aurait moyen de jouer sur le paramètre key_buffer_size. Sa valeur par défaut doit être de 8Mo ce qui ne servira pas à grand chose avec ces volumes. Ce serait bon à prendre d'arriver à garder les indexes en mémoire au moins, mais même ça va être difficile (du moins sur un portable avec 2Go de RAM).