Mauvaises performances de Mondrian avec dimensions dégénérées

Question

J'ai une application qui recueille des métriques de performance et les stocke dans un datamart. J'utilise ensuite Mondrian pour permettre l'analyse et l'exploration ad-hoc des données. Je collectionne environ 5e6 lignes par jour et la taille totale de la table METRIC est d'environ 300M lignes. Nous "colorons" nos données en fonction de la comparaison des métriques avec un accord de niveau de service (SLA). Il y a exactement 5 valeurs distinctes pour la couleur. Lorsque nous faisons des requêtes MDX simples pour obtenir, par exemple, une distribution de couleur des données pour une plage de dates, disons 1 jour, nous voyons des requêtes comme ci-dessous:

2014-06-11 23: 17: 08042 DEBUG [sql] - 223: SqlTupleReader.readTuples [[Color]. [Color]]: exécution de sql [sélectionnez "METRIC". "COLOR" comme "c0" de "METRIC" "METRIC" groupe par "METRIC". "COLOR" commande par "" "MÉTRIQUES COULEUR" ASC NULLS DERNIERS] 11/06/2014 23: 17: 58747 DEBUG [sql] - 223:., exec 50704 ms

afin d'améliorer les performances , le datamart comprend des tables agrégées au Les niveaux heure et jour et les deux tableaux agrégés incluent la colonne COULEUR. Je comprends que Mondrian est très dépendante des performances de la base de données sous-jacente, mais il n'y a vraiment aucun moyen de régler cela. Je peux créer un index sur COLOR (car une analyse complète de l'index sera légèrement plus rapide qu'une analyse complète de la table), mais il semble stupide de créer un index avec 5 valeurs distinctes sur une table de 300M. La table d'agrégation de jour a environ 500K lignes et serait beaucoup plus rapide d'exécuter pratiquement la même requête sur cette table, mais Mondrian semble toujours aller à la table de faits de base pour ces requêtes de dimension.

Ma question est, est-il un moyen d'éviter cette requête? Si je ne peux pas l'éviter, est-il possible d'obtenir que Mondrian utilise les tables agrégées pour ce type de requête? J'ai spécifié approxRowCount dans le seul niveau de cette dimension/hiérarchie et cela a éliminé la requête similaire pour obtenir le nombre de valeurs. Je n'ai pas encore creusé dans la source de Mondrian pour déterminer s'il y a une possibilité d'utiliser la table agrégée ou s'il y a une configuration de ma part qui l'empêche.

Modifier clarification:

Je probablement n'a pas fait un bon travail de poser ma question, permettez-moi essayer de clarifier. Ma requête MDX ressemble à:

select [Color].[Color].Members on columns, 
     {[Measures].[Metric Value], [Measures].[Count]} on rows 
from [Metric] 
where [Time].[2014].[June].[11] 

Je peux regarder cela et écrire à la main une requête SQL qui répond à cette requête

select COLOR, avg(VALUE), sum(FACT_COUNT) 
from AGG_DAY_METRIC 
where YEAR = 2014 
    and MONTH = 6 
    and DAY_OF_MONTH = 11 
group by COLOR 

Les réponses de la base de données de cette requête dans environ 100ms balayage environ 4K lignes. Il faut plusieurs minutes à Mondrian pour répondre à la requête car plusieurs requêtes ne répondent pas directement à la requête MDX, mais obtiennent plutôt des informations sur la dimension . Dans le cas ci-dessus, la base de données doit balayer 300M lignes, en prenant 50 secondes, pour retourner qu'il y a 5 couleurs possibles . Si la couleur était dans une table de dimension normale, il n'y aurait que 5 lignes, mais dans une dimension dégénérée, il pourrait y avoir 100s de millions de lignes.

Mes questions sont les suivantes:

a) Est-il possible de dire Mondrian les valeurs d'une dimension dégénérée et éviter ces requêtes?B) Existe-t-il un moyen pour Mondrian de répondre à ces requêtes à partir de tables agrégées?

Answer 1

Ce problème a été résolu, non en modifiant quoi que ce soit dans le schéma Mondrian ou l'application, mais dans la base de données. La base de données dans ce cas était Oracle et nous étions en mesure de créer une vue matérialisée avec la réécriture de la requête activée.

La vue matérialisée est créée à partir de la requête exacte émise par Mondrian. Puisque les valeurs de couleur ne changent pas très souvent (presque jamais dans notre cas), la vue matérialisée effectue un rafraîchissement complet une fois par jour.

Dans ce cas, les requêtes allaient de minutes en millisecondes. Si vous faites face à un problème comme celui-ci et votre base de données est Oracle, c'est une bonne approche pour accélérer la résolution des tuples pour les dimensions dégénérées avec une faible cardinalité.

Answer 2

Il est difficile de donner des directions spécifiques sans en savoir plus sur votre schéma, mais il me semble que vous devez vous assurer que le nombre de lignes avec certaines couleurs (nombre) doit être marqué comme une mesure globale (Count ou Max Number).

Veuillez noter que ces agrégats ne sont pas calculés en continu (je pense que ce serait trop lourd pour le magasin de données de sauvegarde, et Mondrian ne gardera pas un ensemble fluide en mémoire pour les faits entrants).

L'agrégation peut être spécifiée pour être exécutée/reconstruite à des moments spécifiques (tous les soirs, toutes les heures ...). Cela rendrait Mondrian un peu inadapté à l'analyse en temps réel, mais vous devriez être capable de faire des requêtes presque instantanées sur les données historiques.

Answer 3

Si votre dimension a 5 valeurs distinctes dans une table de faits 300M, elle ne devrait pas être une dimension dégénérée. Il devrait être dans une table de dimension séparée. Une dimension dégénérée ne doit être utilisée que si sa cardinalité est proche du nombre total de lignes de la table des faits, ce qui rend inutile un tableau séparé, car il n'y aurait pas d'économies de stockage significatives et la jonction des résultats de dimension dans beaucoup de données lues;

Si vous placez les couleurs sur une table d'ombrage séparée, toute requête "Read Tuples" retournera les résultats dans quelques ms, et votre problème est résolu. Cependant, plus au sujet de votre question, Mondrian devrait être en mesure de choisir les valeurs de dim à partir des tables agg. Sauf si vous avez des agrégateurs à nombre distinct dans le cube, auquel cas vous êtes dans une situation délicate (à moins qu'il y ait une table agg correspondant exactement au niveau de détail dont vous avez besoin, Mondrian va très probablement scanner la table de faits).

Vous devez également définir l'attribut highCardinality de cette dimension dégénérée sur True. Même avec seulement 5 valeurs distinctes, avoir highCardinality = false indique à Mondrian qu'il est possible d'analyser toute la dimension en toute sécurité pour remplir la liste des membres. Le définir sur true arrête ce scan.

Vous devez également ajouter un index à cette colonne. C'est toujours une bonne idée d'ajouter des index à chaque clé et de dégénérer une colonne de dimension dans une table de faits. Avec un index, la base de données devrait répondre beaucoup plus rapidement à cette requête SQL. Enfin, vous disposez d'une table de faits de ligne 300M. Quel SGBD utilisez-vous? Est-ce une colonne orientée DB? Si non, vous devriez les essayer comme une alternative possible à votre magasin de données. Les DB axés sur les colonnes ont une augmentation significative des performances par rapport aux DB orientées Row pour les requêtes de type Mondrian. Il y a quelques bonnes options là-bas, vous devriez tester les conduire.