> Tech > Partitionnement fondé sur l’utilisation

Partitionnement fondé sur l’utilisation

Tech - Par iTPro - Publié le 24 juin 2010
email

Vous pouvez partitionner un cube en fonction de n’importe quel n-uplet de membres, à n’importe quel niveau d’une dimension quelconque.

Le Partition Wizard d’Analysis Services appelle ce type de n-uplet une tranche de données. Bien qu’Analysis Services puisse analyser une petite partition plus rapidement qu’une partition de grande

Partitionnement fondé sur l’utilisation

taille, la version réduite contient moins de membres. Pour couvrir le même nombre de membres que dans une partition importante, Analysis Services peut être amené à effectuer plus d’analyses de multiples partitions de petite taille. Par conséquent, le temps et les ressources nécessaires à l’exécution de calculs sur le résultat de plusieurs partitions peuvent annuler l’avantage de la rapidité d’analyse procurée par chacune des partitions de taille réduite.

Le choix du partitionnement d’un cube dépend des requêtes que vous allez exécuter. En toute logique, vous pouvez décider de partitionner en fonction de tout n-uplet spécifié par une requête. Par exemple, pour améliorer les performances du listing 2, vous pouvez être tenté de partitionner en fonction de chaque n-uplet de la jointure croisée de {Time.[1998], Time.[1999], Time.[2000]}, [Occupant_ Severity].Members (6 membres) et [Street].[Street_ List].Members (environ 30 000 membres). Dans ce cas, vous allez créer des partitions sur un total de 540°000°n-uplets (3 x 6 x 30 000 = 540°000). Ce plan, en apparence simple, aboutit à deux problèmes. Premièrement, l’analyse de 540°000 partitions et la synthèse de 3 années pour chaque n-uplet de gravité et d’intersections (soit 180°000 n-uplets au total) aura une incidence non négligeable sur les performances. Deuxièmement, le temps et le travail nécessaires à la création et au traitement de 540°000 partitions, que ce soit manuellement pour par programmation à l’aide d’objets DSO (Decision Support Objects), sont astronomiques.

La charge excessive ainsi générée en termes de performances lorsque vous partitionnez en fonction de chaque nuplet d’une requête constitue un problème sérieux pour un certain nombre de raisons. Premièrement, la requête du listing 2 n’est pas supposée retourner chaque année individuellement.

Elle droit renvoyer uniquement le cumul des incidents sur 3 ans. Un partitionnement efficace inclura les trois années spécifiées afin qu’Analysis Services calcule uniquement la somme au sein de la partition. Deuxièmement, la requête ne se contente pas d’accéder à une seule intersection, mais analyse toutes les intersections indépendamment des partitions créées. Le fait de pouvoir accéder directement à une intersection spécifique n’améliore pas les performances car il reste nécessaire de parcourir toutes les partitions.

Il vaut mieux conserver toutes les intersections dans la même partition. Le point crucial est que vous devez partitionner en fonction d’un n-uplet uniquement si la partition évite à votre requête d’effectuer une analyse séquentielle pour le n-uplet en question.

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Tech - Par iTPro - Publié le 24 juin 2010