2014-08-29 11 views
5

ho costruito un modello in icCube sulla cima di una codeblock contabilità generale, che ha le seguenti dimensioni (non limitativo):MDX - grande crossjoin con non vuoto - come ottimizzare le prestazioni

  • Tempo
  • Entity
  • centro di costo
  • account
  • partito intercompany
  • Progetto
  • Attività
  • Numero (questo è il valore)

Con questo modello caricato in una pianificazione strumento, v'è un problema di prestazioni quando si hanno più di 3 dimensioni sugli assi X crollati fino al livello inferiore.

stavo cercando di verificare se icCube in grado di gestire questo meglio, ma la dichiarazione con 3 dimensioni mi ci sono voluti più di 1700 secondi:

select [Dec] on 0 
, non empty { Descendants([Account].[Account].[Total],,leaves) } 
    * { Descendants([Activity].[Activity].[Total],,leaves) } 
    * { Descendants([CostCenter].[CostCenter].[Total],,leaves) } on 1 
from finance 

La ragione di avere dimensioni multiple sulle righe è che gli utenti vogliono vedere quanti più dettagli possibili del codice, preferibilmente il codice completo.

Sono stato sfidato dal fatto che altri strumenti in grado di gestire questo tipo di cose molto facilmente in quanto non ha un database OLAP sottostante ma esegue una query direttamente sulle celle di dati utilizzando le gerarchie. La stessa prestazione si ottiene quando si esegue una query su un estratto dei dati in Excel (non ci sono così tante righe di dati).

Informazioni sui dati:

  • Le dimensioni sono abbastanza enorme: 400 conti, 6000 + attività, 50 soggetti, 500 CostCenters
  • Dimensioni attività e progetto sono molto piatto (quasi nessuna struttura)
  • Ci sono solo 50.000 importi, quindi i dati sono molto sparsi

Qualche suggerimento o suggerimento su come risolvere questo?

risposta

4

E 'il classico problema di MDX, pena la creazione di antipattern MDX e metterlo come il numero 1.

Il crossjoin che stai calcolo produrrà 400x60000x500 = 12000000000 (^ 9 12x10) tuple e stiamo chiedendo di valutare ciascuno di loro. Questo fa molte valutazioni al secondo.

Sembra un modo "strano" fare un drill-through. Proverei per un drillthrough ma proviamo a risolverlo in MDX:

La soluzione sta cercando di ridurre il numero di tuple generate eseguendo uno nonempty il prima possibile.Quindi:

noempty(noempty(A) x noempty(B)) x noempty(C) 
    or 
noempty(A) x noempty(noempty(B) x noempty(C)) 

Utilizzando la prima versione con un paio di meno non vuota:

select 
[Dec] on 0, 
nonempty( 
    nonempty( 
     Descendants([Account].[Account].[Total],,leaves) 
    * nonempty(Descendants([Activity].[Activity].[Total],,leaves) , [DEC]) 
    , [DEC]) 
    * { Descendants([CostCenter].[CostCenter].[Total],,leaves) } 
, [DEC]) 
on 1 
from [finance] 

In icCube si creerebbe un Function che esegue questa operazione per semplificare la sintassi:

Function megaCrossjoin1(A,B,C,M) as nonempty(nonempty(A,M) * nonempty(B,M), M) * nonempty(C,M) 

e usalo

megaCrossjoin1( 
    Descendants([Account].[Account].[Total],,leaves) , 
    Descendants([Activity].[Activity].[Total],,leaves) , 
    Descendants([CostCenter].[CostCenter].[Total],,leaves) , 
    [Dec]) 

spero che aiuti

+0

Nel mio caso l'uso di questa tecnica ha reso impossibile un cross join altrimenti gestibile. –