Juste un truc et ce quelque soit la base de données :
50 tables / 100 000 lignes sur chaque (environ 5 millions de lignes)
taille moyenne de la ligne ? on prendra 1024 octets ... donc avec 5 Go de RAM pour la base de données tout tient en mémoire. Prend un serveur avec 16 Go et cela doit rouler.
C'est un bon onduleur qu'il te faut :)
Après c'est le nombre d'utilisateurs et la gestion de la concurrence d'accès.
Si 1 utilisateur bloque l'accès à une donnée, alors tout les autres attendent.
et pourtant tu as la plus belle base et machine du monde.
Tout cela pour vous dire que en générale les problèmes de performances ont pour origine
5% : proviennent de l'OS
10 % : proviennent de la base de données (paramétrage allocation mémoire etc ...)
le reste : Conception de la base et développement soit 85%
ce n'est pas péjoratif ce que je vais dire, mais sur de petit volume comme celui la, la performance ne devrait pas se poser en terme de base de données.
Honnêtement avec des disques SSD et 2 bon CPU, 16 Go ou plus de RAM sur ce volume je ne vois pas le problème même avec plusieurs centaines d'utilisateurs.
J'ai récemment testé des disques SSD capables de copier 30 Go / minutes, avec une base oracle de 250 millions de lignes (la table fait plusieurs Go) le CPU était au max AVANT les disques.
Par contre, si il s'agit de sortir par jour plusieurs milliers de documents (Etiquettes, Bon de livraisons etc ...) il faut réfléchir à paralléliser avec un serveur de base de données et plusieurs serveurs de traitements etc ...
L'architecture doit prendre en compte tout les paramètres : de l'utilisateur aux disques dur en passant par les devs, ceux qui signent les chèques, le réseau etc ...
Et puis avant de faire une application de compét' penser aussi à la pérennité, la sauvegarde, la facilité de maintenance ...
[^] # Re: contexte ?
Posté par Christophe B. (site web personnel) . En réponse au message Performances des SGBD. Évalué à 2. Dernière modification le 17 décembre 2014 à 11:03.
Juste un truc et ce quelque soit la base de données :
50 tables / 100 000 lignes sur chaque (environ 5 millions de lignes)
taille moyenne de la ligne ? on prendra 1024 octets ... donc avec 5 Go de RAM pour la base de données tout tient en mémoire. Prend un serveur avec 16 Go et cela doit rouler.
C'est un bon onduleur qu'il te faut :)
Après c'est le nombre d'utilisateurs et la gestion de la concurrence d'accès.
Si 1 utilisateur bloque l'accès à une donnée, alors tout les autres attendent.
et pourtant tu as la plus belle base et machine du monde.
Tout cela pour vous dire que en générale les problèmes de performances ont pour origine
5% : proviennent de l'OS
10 % : proviennent de la base de données (paramétrage allocation mémoire etc ...)
le reste : Conception de la base et développement soit 85%
ce n'est pas péjoratif ce que je vais dire, mais sur de petit volume comme celui la, la performance ne devrait pas se poser en terme de base de données.
Honnêtement avec des disques SSD et 2 bon CPU, 16 Go ou plus de RAM sur ce volume je ne vois pas le problème même avec plusieurs centaines d'utilisateurs.
J'ai récemment testé des disques SSD capables de copier 30 Go / minutes, avec une base oracle de 250 millions de lignes (la table fait plusieurs Go) le CPU était au max AVANT les disques.
Par contre, si il s'agit de sortir par jour plusieurs milliers de documents (Etiquettes, Bon de livraisons etc ...) il faut réfléchir à paralléliser avec un serveur de base de données et plusieurs serveurs de traitements etc ...
L'architecture doit prendre en compte tout les paramètres : de l'utilisateur aux disques dur en passant par les devs, ceux qui signent les chèques, le réseau etc ...
Et puis avant de faire une application de compét' penser aussi à la pérennité, la sauvegarde, la facilité de maintenance ...