[architecture] process d'historisation

**P'tit Jean** · 21/10/2003, 16h37

Bonjour,

je voudrais avoir quelques renseignements concernant un probleme fréquemment rencontré : l'historisation de données.

Voici mon probleme :

Dans mon schema, j'ai une table de 5,300,000 enregistrement, cette table contient un certain nombre de données qui ne sont pas utilisées au quotidien mais qui ne peuvent etre purgees. La cause de cette historisation est notamment la volumetrie et le temps mis pour faire des dumps load de ce schema (au total la base fait 18Go).

La solution que nous envisageons consiste a creer un schema d'historisation contenant la meme structure de table dans laquelle on stockerait ces données via soit une procédure stockée soit un batch.

Mon probleme reside dans la recuperation de ces donnees (c'est a dire lorsque l'on souhaite pouvoir acceder de nouveau a des donnees historisees, pour eventuellement les utilisees en meme temps que celle non historisees).

La solution vers laquelle je m'oriente serait l'utilisation d'une vue celle ci serait une vue des deux tables.

avant : Mes_data (Table) Mes_data_Histo (Table)
apres : Mes_data (Vue) Mes_data_prod (Table) Mes_Data_Histo (Table)

Ceci me permettant de ne pas avoir a reprendre toutes les sources qui accedent par SQL a la table Mes_data.

SGBD : Sybase

Y voyez vous une grossiere erreur ?
Quel va etre le comportement de ma vue d'un point de vue de gestion par le SGBD (cela va t il etre plus lent que l'utilisation d'une Table de 5300000 lignes) ?

Je suis pas certains d'avoir ete bien clair alors hesitez pas a me demander plus de renseignement.

Merci

**Fabien Celaia** · 21/10/2003, 18h06

Ca depend des indexes que tu as sur tes tables...

L'acces a une vue est identique a celui des tables connexes

Attention avec Sybase ASE : l'union dans une vue n'est possible que depuis la version 12.5

**SQLpro** · 22/10/2003, 09h15

Si tu veut de la performance extrême, j'utilise un concept très différent :

1) une base complète avec tous l'historique y compris les dernières données, alimentée par réplication sur INSERT et UPDATE, jamais en DELETE sur un serveur de moyenne gamme

2) la base d'exploitation limitée à l'année en cours plus l'année précédente.
sur un serveur très performant.

Si l'utilisateur veut des infos plus ancienne, aucune requête n'est modifiée, seule la connexion change et les temps de réponse aussi, mais c'est l'utilisateur qui est demander de ces info ancienne et il prend conscience de l'allongement des temps de réponse et l'accepte facilement compte tenu de sa demande.

A +

**Fabien Celaia** · 22/10/2003, 11h05

Dans un environement pur Sybase, il m'est arrivé d'installer la même technique que SQLPro, mais avec la base historisée sur ASIQ plutôt que sur ASE, compte tenu que la plupart des requêtes historiques l'étaient en mode SELECT (pour des rapports). Quant a la repli, modification des functions strings pour qu'une modification dans la base de prod amene une insertion + date dans la base DW (c'est un peu plus complexe que ca dans le detail)

**P'tit Jean** · 22/10/2003, 11h27

J'ai deja employe une technique similaire a la votre.

Nous disposions d'une base d'historique pour un perimetre bien defini. Cette base etait alimente regulierement et accessible par les user en mode lecture.

Mon soucis aujourd'hui c'est que je ne peux pas mettre une telle solution en place.

Il s'agit d'une base de données liees a un SI financier gerant un certain nombre de produit financier. De nombreux traitements sont necessaires (calcul de risque financier, de valorisation, de PNL ... bref des calculs financiers tres lourd). Pour soulager la base principale, la solution qui a ete adoptee par l'equipe fut de creer trois autres bases dedies chacune d'entre elle pour des calculs specifiques.

Chacune de ces base correspond a une image de la base principale a une heure donnee (par exemple une des bases est une image de la principale en date de la veille a 23h59). Ces images sont donc faite par dump/load.
Le probleme est que nous ne disposons pas de beaucoup de temps pour faire ces dump/load et que nous ne devons pas utiliser de replication ... (me demander pas pourquoi ca m'herisse le poil).

La problematique est donc de reussir a alleger la taille de la base principale (et par dump/load interpose des autres bases) afin de diminuer ce temps de dump/load.

La solution que j'envisage est de mettre sur une base une partie des donnees statiques ou non utilisees, et que cette base soit accessible par l'ensemble de mes bases (cela represente tout de meme 1/3 de la volumetrie). Mon dump/load ne se faisant alors uniquement que sur les 2/3 restants.

Le fait d'utiliser une vue qui represente une table "light" plus ma table d'historique me permet d'etre transparent vis a vis de l'utilisateur, et de mes programmes.

Ma question est plus de savoir si cela semble correcte comme idee et de savoir quels sont les impacts sur les perfs (le fait de splitter les data sur deux bases differentes et d'y acceder par une vue est il beaucoup plus lent que d'acceder par une seule table).

merci de vos conseils !