Quelle charge serveur/config il me faut ?

[USA Mike]

bonjour,

c'est ma première fois que je fais faire ceci, alors je suis un peu dans les nuages : estimer la config d'un serveur Mysql en fonction de données.

Le schéma sera à 10 tables dont une centrale qui servira pour des stats.
La majeure partie des requêtes seront avec des GROUP BY, HAVING, imbriquées, jointures..etc.
Chauqe jour, il y aura en plus dans la table principal 15000 nouveaux tuples (lignes).
Je n'ai pas parlé des autres tables car elles sont minimes (tables à 2 champs , 1id, un nom, des trucs genre catégories, à 10 ou 20 lignes maxi)

Au pire, il y aura 50 utilisateurs qui feront des requêtes en même temps.

Ca que j'arrive pas à déterminer c'est d'une part la puissance du CPU, la qté de RAM et eventuellement (car on peut voir large pour ça) le disque dur.


une idée de comment s'y prendre ?

[SQLpro]

Très petite base... A vu de nez, si les lignes de ta table ne sont pas trop longue en octets (moins de 200), je dirais qu'un bi pro (pour le confort) avec 2 Go de RAM et 5 disques (RAID 1 + RAID 5) devrait largement suffire.
Soit 2 agrégats de disques avec une taille de 75 à 150 Go.

Attention soit exigeant sur les disques. Mieux vaut du 15 rpm que n'importe quoi. En revanche le processeur dernier cri n'a strictement aucun intérêt.

A +

[USA Mike]

vraiment ?
15000 nouvelles lignes en plus par jour à brasser est donc si petit ?
au bout d'un mois ça fait 450000, au bout de 1 an c'est 900 000 tuples !
je pensais que pour faire 'rapidement' des requêtes du genre GROUP BY/HAVING/imbriqué il fallait plus de mémoire et plus de puissance si on veut pas attendre devant l'écran..

[SQLpro]

Le nombre de ligne n'a aucune signification.
Un million de grain de sable tient dans un seau.
Un millions de paquebot ne tiendrons pas dans le même seau !

C'est le volume des données qui doit être considéré et non le nombre de lignes.

A +

[USA Mike]

sauf erreur de ma part, le volume de données dépend directement du nombre de ligne ! et en plus du traitement.

[Jester]

A 200 octets la ligne, ça prend 1Go par an.

Ce qui implique qu'avec pas mal de RAM (2 au moins) on peut faire tenir le tout en mémoire et donc avoir des performances exceptionnelles.

Par exemple sur une machine à 1GHz (processeur Via C7, ridicule) et 1Go de RAM, sur une table InnoDB de 4 millions d'enregistrements pour 200Mo, cela me prend 2-3 seconde pour une requête qui lis toutes les lignes (avec where, order by, group by et having, sans jointures). 20 secondes environs si ce n'est pas dans le cache.

Par contre 50 utilisateurs concurrents?

[USA Mike]

mais quand la requête commence à être compliqué avec des structures dans le selectn de quoi obtenir des résultats en pourcentage , avec des cases..Etc


bref ça craint...

[Jester]

D'où une solution fort classique => faire des tests quitte à simuler des données.

Vous aurez une meilleure vue de ce qu'il vous faut et de ce qu'il faut faire.

[SQLpro]

mais quand la requête commence à être compliqué avec des structures dans le selectn de quoi obtenir des résultats en pourcentage , avec des cases..Etc

Il suffit de mettre les bon index ! (il faut aussi avoir un bon optimiseur SQL)
Pour vous en convaincre, lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/optimisation/indexation/
Pour une table de 120 millions de ligne on passe d'un coût de requête de 36 000 au mieux sans index à un coût de 2 après la pose du meilleur index !

A +