optimisatiser la structure d'une base de données... - SQL/NoSQL - Programmation
Marsh Posté le 28-04-2006 à 12:23:37
clems07 a écrit : Bonjour à tous! |
Conceptuellement, une table doit regrouper l'ensemble des enregistrements de même nature. Surtout qu'à chaque nouvelle table, la structure générale de la BDD s'alourdit "considérablement" (elle contient en interne la table des table, la table des colonnes, la table des index, etc et chaque nouvelle table rajoute des éléments à toutes ces tables internes).
Donc il vaut mieux une seule table pour tous tes enregistrements plutôt que plusieurs tables.
En ce qui concerne une bdd par années, ça ne dépend que de ton besoin. Si tes requêtes ne concernent qu'une seule année, ça ira. Mais si t'as besoin d'infos sur plusieurs années en même temps, tu seras obligé d'alourdir ton code pour tout récupérer.
T'en fais pas pour le volume des infos. Ca te semble peut-être énorme mais les BDD ont justement été créées pour stocker et rechercher des données en grand nombre. En un an il y a 525960 minutes et si chaque info fait 1/2ko (512 octets ce qui permet de stocker quand-même 64 valeurs au format "double" ), ton poids d'info pour un an ne sera que de 256Mo. Face à la puissance des disques qui travaillent en Go, c'est pas vraiment un poids énorme...
Marsh Posté le 28-04-2006 à 13:57:22
merci Sve@r
En effet je vais avoir des requêtes concernant plusieurs années...
Donc s'est peut etre pas une bonne solution de faire une bdd par an.
Sinon la taile de la bdd sur le disque n'est pas ce qui m'importe le plus...
En fait cette bdd doit etre accessible dans l'avenir sur le net!
Je cherche donc la meilleure architecture pour que les requètes s'executent le plus rapidement possible...
ne crois tu pas que l'accés a un enregistrement dans une table contenant plusieurs centaines de milliards de lignes risque de prendre du temps?
(en effet, 20 000 stations faisant une mesure par minute pendant 30 ans = 315 360 000 000 valeurs!)
Marsh Posté le 29-04-2006 à 10:29:12
clems07 a écrit : Sinon la taile de la bdd sur le disque n'est pas ce qui m'importe le plus... |
En général, avec les index, la recherche est très rapide surtout si les index sont construits en arbre (une recherche sur "n" valeurs ne fait que "log(n)/log(2)" comparaisons) mais avec 3Go d'enregistrements, je suis dubitatif (surtout qu'il faut prendre en compte la taille d'un enregistrement)...
Ca semble un projet de haut niveau. Si c'est le cas et qu'il est soutenu par des moyens financiers, tu pourras déporter ta bdd sur un gros calculateur...
A ce niveau là, tu peux pas te lancer à l'aveuglette. Faut que tu fasses des tests, que tu génères artificiellement (avec un shell par exemple si t'es sur de l'Unix) tes 3Go d'enregistrements puis que tu les injectes dans différentes bdd pour les évaluer.
Bon, j'ai d'ailleurs présumé que tu étais sur de l'Unix (ou apparenté) mais c'est à mon avis indispensable. C'est universellement connu que Unix/Linux est plus rapide que zindoz pour ce genre de travail...
Marsh Posté le 29-04-2006 à 11:24:56
c'est pas linux ou unix qui fait la rapidité, mais le type de plateforme. Une plateforme unix est bien plus performante (plus chère aussi) qu'une plate forme PC. C'est de gros calculateur généralement qui sont optimisé pour ce genre de travail. Je ne serais pas convaincu qu'une BDD sous LINUX tournerait plus vite que sur Windows. Absolument pas convaincu la... Par contre entre une plateforme pc et une unix, il n'y a pas photo
Marsh Posté le 29-04-2006 à 11:48:57
clems07 a écrit : en effet, 20 000 stations faisant une mesure par minute pendant 30 ans = 315 360 000 000 valeurs! |
Oui mais la plateforme utilisée évoluera en 30 ans...
Marsh Posté le 28-04-2006 à 12:04:04
Bonjour à tous!
Après plusieurs recherches sur le forum... je me lance à faire ce nouveau sujet.
Voila je dois concevoir une base de données qui est amenait à recueillir un nombre impressionant d'enregistrements...
En effet ce sont des valeurs mesurées par des stations météo...
Jusque la ca va... mais le souci c'est que certaines stations relevent des mesure toutes les minutes pendant plusieurs années... ce qui commence à faire énorme...
Je ne m'attarde pas pour le moment sur les objectifs de la base de données. (on verra plus tard si c'est vraiment necessaire!)
Ma question est plus générale:
Pour accéder a des données lorsqu'on en stock une masse impressionante, est-il plus judicieux de multiplier le nombre de tables contenant peu d'enregistrements ou de garder des tables avec plus de champs et d'enregistrements?
Sinon est ce que construire une base de donnees par année peu etre une bonne solution?
De se fait en terme de temps d'accé, quel est le moins couteux: l'ouverture de la base, la jointure entre 2 tables ou le balayage d'une table?
Merci de pouvoir m'éclaircir à ce sujet...