gain stockage olap [Résolu]

[colomban]

Bonjour,
c'est mon premier post, j'espères ne pas me tromper de forum.
Je travaille sur les bases de données décisionnelles et je suis surpris de constater que le coût de stockage des cubes OLAP est extrèmement faible (stocké en MOLAP)!
Pour une base de données de 10Go, je n'aperçois que quelques Mo de surplus au chargement des données dans le cube OLAP.
Je précise qu'il s'agit s'un mode de stockage MOLAP donc que les données sont effectivement dupliquées.
Je suis bien conscient que les données peuvent être comprimées mais je trouve le gain un peu énorme (vous me direz tant mieux).
J'ai cependant peur d'avoir loupé quelque chose alors si quelqu'un peut me dire le rapport de gain attendu en coût de stockage OLAP, je l'en remercie d'avance.
P.S Je travaille avec le module Analysis Service de SQL Server

[Pomalaix]

Bonjour

Bon, on va supposer que vous avez non seulement défini votre cube, mais que vous l'avez aussi réellement "exécuté", donc calculé et rempli.

Tout dépend de ce que vous avez mis dedans. Quelle portion de données OLTP prenez-vous initialement, et quel est le niveau de vos données détaillées ? Combien y a-t-il de valeurs différentes dans vos dimensions ? Combien avez-vous de dimensions ? Sont-elles hiérarchisées ou plates ?

Si vous travaillez uniquement à un niveau très agrégé, avec peu de valeurs dans les dimensions, il peut être tout à fait normal que votre cube soit très peu volumineux.

[colomban]

Bonjour Pomalaix et merci de t'intéresser au problème,
J'ai 6 dimensions dans mon cube répartis sur cinq tables de dimensions plates (modèle en étoile).
Les tables de dimensions sont peu volumineuses (pour OLAP) un maximum de 400 000 lignes pour la table Contact. Par contre, la table de faits pèse quand même 300 millions de lignes.
J'ai choisi le stockage MOLAP et si j'ai bien compris, il stocke toutes les données détaillées des tables dans le cube (à la différence de ROLAP et HOLAP). C'est pour cela que je suis étonné de constater que le coût de stockage est négligeable : 7 Mo pour 300 millions de lignes !
Je précise qu'il n'y a pas beaucoup de colonnes dans la table de faits (uniquement 6 clés et 4 mesures) et que leurs tailles sont réduites mais tout de même.
Au niveau des dimensions, elles sont aussi simples avec environ 4 niveaux.
Mais bon, si vous me dites que c'est normal après tout tant mieux.
Je suis juste surpris.

[Pomalaix]

Attention, je ne dis pas que C'EST normal, je ne suis pas dans vos données.
Je dis juste que ça peut l'être parfois, du fait du principe même de l'agrégation, dont l'effet réducteur dépend de la granularité et du nombre des dimensions combinées.

Illustration numérique :
Disons qu'on a une table de faits décrivant des ventes, de 100 millions de lignes occupant chacune 50 octets, soit donc 5 Go pour la table de faits.
On va examiner le chiffre d'affaires en fonction de la date (niveau jour, semaine ou mois), du rayon (20 rayons différents) et du magasin (5 magasins).
Au niveau le plus détaillé, on stockera donc 365*20*5 soit 36500 valeurs. Si on suppose que chaque cellule du cube, dans ces conditions, prend 50 octets de stockage, on occupe 1,8 Mo.
Dans l'hypothèse où on précalcule les agrégats en ne descendant qu'au niveau de la semaine, et non plus du jour, on divise encore le volume par 7.
Si de plus on prend en compte une compression automatique des données et un traitement intelligent des cellules creuses dans le cube, on peut donc avoir des cubes très petits au regard de la table de faits initiale.

J'espère que ça vous permettra de juger si votre situation est normale ou pas.

[colomban]

merci de ton exemple, c'est maintenant beaucoup plus clair dans mon esprit.

[colomban]

un affreux doute m'envahit soudain.
Les données ne sont pas réelles. En effet, pour juger des performances sur de grands jeux de données, j'ai dupliqué plusieurs fois mes données existantes. Est-il possible que l'ordinateur en profite pour effectuer des optimisations qui ne sont pas possibles d'habitude?