Question

Je me demande s'il y a des conséquences sur les performances de l'ajout d'un grand nombre de membres calculés à mon cube. D'une part, il est agréable d'avoir des choses une fois définies, situées au centre, testé et disponible pour une utilisation de tout client qui ne supporte pas MDX. D'autre part, certains de ces membres, je suis d'ajouter pourrait ne pas être utilisé très souvent, donc je pouvais les en ligne dans un ou deux rapports qui pourraient en avoir besoin.

Mis à part le fouillis d'avoir des membres inutiles traîner, dois-je garder le nombre de membres calculés le plus petit possible? Est-ce que plus d'augmenter le temps de traitement du cube? Vont-ils ralentir les requêtes qui n'utilisent pas les membres calculés?

Était-ce utile?

La solution

Les membres calculés ont peu d'effet sur le traitement, ni sur d'autres questions. Ajoutez autant que vous le souhaitez!

La raison en est qu'ils viennent d'être définies sur le cube, mais en fait évalué à l'exécution . Par conséquent, les seules questions qui seront ralenties ou touchées sont les requêtes qui les utilisent. Attendez-vous à revenir un peu plus lent que les membres natifs pour cette raison, aussi.

Rechercher toutes les occasions de faire le membre calculé une partie réelle de votre cube s'il est utilisé très fréquemment. , Apprendre et aimer aussi la déclaration de scope. Même si un membre calculé qui est scoped est toujours calculée lors de l'exécution, l'instruction scope il fournit un plan d'exécution tout prêt, il a tendance à être plus rapide. Je vais créer souvent un membre de la DSV et scope alors pour mes gros volumes membres calculés.

Autres conseils

Chaque fois que vous pouvez pousser les calculs de nouveau dans le modèle relationnel, il augmentera les performances des requêtes MDX; mais aussi avoir un impact négatif sur les performances de traitement.

Si vous pouvez pré-calculer des mesures à l'aide en ligne logique SQL, puis exposer ces mesures comme dans votre vue de source de données. Le moteur de stockage peut construire des agrégats et le moteur de formule aura moins de travail à faire. Vous poussez fondamentalement la soulever des charges lourdes jusqu'à sql. Cela fonctionne très bien pour les facteurs de calcul statiques et de conversion et des choses comme l'arithmétique simple, etc.

Une autre chose que vous pouvez faire est de créer des membres calculés intermédiaires qui ne devraient pas être utilisés par l'utilisateur final comme caché, cela n'aura aucun effet sur la performance; mais désencombrer le cube de l'utilisateur final perspective.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top