Buon esempio di MDX vs SQL per query analitiche

Qualcuno può mostrarmi un buon esempio dei vantaggi di MDX rispetto al normale SQL quando si eseguono query analitiche? Vorrei confrontare una query MDX con una query SQL che fornisce risultati simili.

Wikipedia dice :

Mentre è possibile tradurre alcuni di questi in SQL tradizionale, spesso richiederebbe la sintesi di espressioni goffe di SQL anche per espressioni MDX molto semplici.

Ma non c'è né una citazione né un esempio. Sono pienamente consapevole che i dati sottostanti devono essere organizzati in modo diverso e OLAP richiederà una maggiore elaborazione e archiviazione per inserto. (La mia proposta è di passare da un RDBMS Oracle ad Apache Kylin + Hadoop )

Contesto: sto cercando di convincere la mia azienda che dovremmo interrogare un database OLAP anziché un database OLTP. La maggior parte delle query SIEM fa ampio uso di raggruppamento, ordinamento e aggregazione. Oltre all'aumento delle prestazioni, penso che le query OLAP (MDX) sarebbero più concise e più facili da leggere / scrivere rispetto all'equivalente OLTP SQL. Un esempio concreto porterebbe il punto a casa, ma non sono un esperto di SQL, tanto meno MDX ...

Se aiuta, ecco una query SQL di esempio relativa a SIEM per eventi firewall verificatisi la scorsa settimana:

SELECT   'Seoul Average' AS term, 
         Substr(To_char(idate, 'HH24:MI'), 0, 4) 
                  || '0'        AS event_time , 
         Round(Avg(tot_accept)) AS cnt 
FROM     ( 
                SELECT                     * 
                FROM   st_event_100_#yyyymm-1m# 
                WHERE  idate BETWEEN trunc(sysdate, 'iw')-7 AND trunc(sysdate, 'iw')-3 #stat_monitor_group_query#
                UNION ALL 
                SELECT * 
                FROM   st_event_100_#yyyymm# 
                WHERE  idate BETWEEN trunc(sysdate, 'iw')-7 AND trunc(sysdate, 'iw')-3 #stat_monitor_group_query# ) pm
GROUP BY substr(to_char(idate, 'HH24:MI'), 0, 4) 
                  || '0' 
UNION ALL 
SELECT   'today' AS term , 
         substr(to_char(idate, 'HH24:MI'), 0, 4) 
                  || '0'        AS event_time , 
         round(avg(tot_accept)) AS cnt 
FROM     st_event_100_#yyyymm# cm 
WHERE    idate >= trunc(sysdate) #stat_monitor_group_query# 
GROUP BY substr(to_char(idate, 'HH24:MI'), 0, 4) 
                  || '0' 
ORDER BY term DESC, 
         event_time ASC

MDXe non SQLsono affatto uguali, e spesso nemmeno paragonabili, in quanto eseguono query multidimensionale relational databasesrispettivamente. Non è possibile eseguire query sul database relazionale esistente con MDX.

Il vantaggio principale dell'utilizzo di un modello multidimensionale e dell'utilizzo di MDX per eseguire query è che si stanno eseguendo query su dati pre-aggregati e che MDX è ottimizzato per eseguire query in modo statistico piuttosto che in modo relazionale. Non si eseguono più query su righe e tabelle per produrre un set di risultati semplice ma si utilizzano tuple e set per suddividere e aggregare un cubo multidimensionale.

Pensala in questo modo: se usi una query SQL per ottenere l'importo totale delle vendite per un particolare gruppo di articoli, dovrai scrivere una query che somma tutte le righe della fattura per tutti gli articoli nel gruppo di articoli. Se si utilizza un cubo e si hanno aggregazioni a livello di gruppo di articoli, il risultato viene calcolato durante l'elaborazione e le aggregazioni vengono archiviate per ciascun gruppo di articoli, rendendo le query istantanee.

Multidimensionale e MDX è un concetto completamente diverso dall'SQL basato su set relazionali.

Il tuo esempio potrebbe diventare molto più semplice perché eseguiresti trasformazioni come l'analisi della data durante il processo di caricamento dei dati e il confronto del mese scorso potrebbe essere un calculated measure. La tua media di Seoul e oggi potrebbe esserecalculated members

Se i tuoi cubi sono ben progettati per le tue esigenze, credo che potresti tagliare e tagliare il set di dati del tuo esempio senza nemmeno dover scrivere query ma farlo in un pivottabile o in un altro strumento di analisi.

Poi di nuovo non c'è "solo riscrittura di SQL in MDX". Richiede un bel po 'di conoscenza per farlo bene e una mentalità diversa. Pensa ai diagrammi di Venn invece che ai set di risultati.

Per fornire un esempio utilizzando il database di Adventureworks, immagina di dover elencare il numero di ordini di vendita per cliente nella categoria bici.

Se lo facessi usando SQL, dovresti scrivere una query che conteggi il numero di ordini di vendita contenenti una linea con un prodotto che appartiene alla categoria bici e unirlo alla tabella dei clienti, in modo che diventi una query abbastanza complessa .

-- need distinct count, we're counting orders, not order lines
SELECT count(DISTINCT soh.salesorderid)
    ,pers.FirstName + ' ' + pers.LastName
FROM sales.SalesOrderDetail sod
-- we need product details to get to the category
INNER JOIN Production.Product p ON sod.ProductID = p.ProductID
-- but we need to pass via subcategories
INNER JOIN Production.ProductSubcategory psc ON p.ProductSubcategoryID = psc.ProductSubcategoryID
-- we finally get to the category
INNER JOIN Production.ProductCategory pc ON psc.ProductCategoryID = pc.ProductCategoryID
-- we also need the headers because that's where the customer is stored
INNER JOIN sales.SalesOrderHeader soh ON sod.SalesOrderID = soh.SalesOrderID
-- finally the customer, but we don't have his name here
INNER JOIN sales.Customer c ON soh.CustomerID = c.CustomerID
-- customers
INNER JOIN Person.Person pers ON c.PersonID = pers.BusinessEntityID
-- filter on bikes
WHERE pc.Name = 'bikes'
-- but the customers table doesn't contain the concatenated name
GROUP BY pers.FirstName + ' ' + pers.LastName;

In MDX (a condizione che il cubo sia ben progettato per questo requisito) potresti semplicemente scrivere perché la logica e la complessità si sono spostate altrove:

SELECT [Measures].[Internet Order Count] ON COLUMNS,
[Customer].[Customer].Members ON ROWS
FROM [Adventure Works]
WHERE [Product].[Product Categories].[Category].[Bikes]

I cubi / database OLAP hanno le seguenti caratteristiche:

• Ottenere informazioni già aggregate in base alle esigenze dell'utente.
• Accesso facile e veloce
• Capacità di manipolare i dati aggregati in diverse dimensioni
• Un cubo utilizza le funzioni di aggregazione classiche min, max, count, sum, avg, ma può anche utilizzare funzioni di aggregazione specifiche.

MDX contro SQL:

MDX è realizzato per navigare nei database multidimensionali e per definire query su tutti i loro oggetti (dimensioni, gerarchie, livelli, membri e celle) per ottenere (semplicemente) una rappresentazione delle tabelle pivot.

MDX utilizza molti identici come parole chiave SQL, come SELECT, FROM, WHERE. La differenza è che SQL produce viste relazionali mentre MDX produce viste multidimensionali di dati .

La differenza si riscontra anche nella struttura generale delle due lingue:

Query SQL: SELECT column1, column2, ..., column FROM table
query MDX:SELECT axis1 ON COLUMNS, axis2 ON ROWS FROM cube

FROMspecifica l'origine dati:
In SQL: una o più tabelle
In MDX: un cubo

SELECT indica i risultati desiderati da recuperare dalla query:

In SQL:

• Una vista di dati in due dimensioni (righe e colonne)
• Le righe hanno la stessa struttura definita da colonne

In MDX:

• Qualsiasi numero di dimensioni per formare i risultati della query.
• Il termine asse utilizzato per evitare confusione con le dimensioni del cubo.
• Nessun significato speciale per le righe e le colonne, ma devi definire ogni asse: axe1 definisce l'asse orizzontale e l'asse 2 definisce l'asse verticale.

Esempio di query MDX:

Misure : Prezzo unitario, Quantità, Sconto, Importo vendite,
Dimensione merci :
Gerarchia temporale : Anno> Trimestre> Mese> con membri:

• Anno: 2010, 2011, 2012, 2013, 2014

• Trimestre: Q1, Q2, Q3, Q4

• Mese: gennaio, febbraio, marzo, ...

Dimensione :
Gerarchia dei clienti : Continente> Paese> Stato> Città con membri:

• Città: Parigi, Lione, Berlino, Colonia, Marsiglia, Nantes ...

• Stato: Loire atlantique, Bouches du Rhône, Bas Rhin, Torino ...

• Paese: Austria, Belgio, Danimarca, Francia, ...

• Livello di continente: Europa, Nord America, Sud America, Asia

Dimensione :
Gerarchia di prodotti : Categoria> Sottocategoria> Prodotto con membri:

• Categoria: Cibo, bevande ...
• Categoria di cibo: Alimento cotto ...
• ...

aggiornamento : questo esempio è meglio:

Obiettivo della query: ottenere l'importo delle vendite e il numero di unità (nelle colonne) di tutte le famiglie di prodotti (nelle righe) vendute in California durante il primo trimestre del 2010

MDX

SELECT  {[Measures].[Unit Sales], [Measures].[Store Sales]} ON COLUMNS,
      {[Products].children} ON ROWS
FROM  [Sales]
WHERE ([Time].[2010].[Q1], [Customers].[USA].[CA])

SQL

SELECT SUM(unit_sales) unit_sales_sum, SUM(store_sales) store_sales_sum
FROM sales
  LEFT JOIN products ON sales.product_id = products.id
  LEFT JOIN product_classes ON products.product_class_id = product_classes.id
  LEFT JOIN time ON sales.time_id = time.id
  LEFT JOIN customers ON sales.customer_id = customers.id
WHERE time.the_year = 2010 AND time.quarter = 'Q1'
  AND customers.country = 'USA' AND customers.state_province = 'CA'
GROUP BY product_classes.product_family
ORDER BY product_classes.product_family

fonte: note di utilizzo per Modrian (che traduce le query MDX da utilizzare su database relazionali)

Ho trovato un esempio decente, sebbene l'SQL non sia molto più complesso (rispetto a SaasBase anziché a MDX):

fonte: "OLAP" in tempo reale per Big Data (+ casi d'uso) - bigdata.ro 2013