Bom exemplo de MDX vs SQL para consultas analíticas

Alguém pode me mostrar um bom exemplo das vantagens do MDX sobre o SQL comum ao fazer consultas analíticas? Eu gostaria de comparar uma consulta MDX com uma consulta SQL que fornece resultados semelhantes.

A Wikipedia diz :

Embora seja possível converter alguns deles em SQL tradicional, seria necessário a síntese de expressões SQL desajeitadas, mesmo para expressões MDX muito simples.

Mas não há citação nem exemplo. Estou ciente de que os dados subjacentes devem ser organizados de maneira diferente e o OLAP exigirá mais processamento e armazenamento por inserção. (Minha proposta é passar de um Oracle RDBMS para o Apache Kylin + Hadoop )

Contexto: estou tentando convencer minha empresa de que deveríamos consultar um banco de dados OLAP em vez de um banco de dados OLTP. A maioria das consultas SIEM faz uso pesado de agrupar por, classificar e agregar. Além do aumento de desempenho, acho que as consultas OLAP (MDX) seriam mais concisas e mais fáceis de ler / gravar do que o SQL OLTP equivalente. Um exemplo concreto levaria o ponto para casa, mas eu não sou especialista em SQL, muito menos MDX ...

Se ajudar, aqui está um exemplo de consulta SQL relacionada ao SIEM para eventos de firewall que ocorreram na semana passada:

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 não SQLsão de modo algum os mesmos, e geralmente nem são comparáveis, pois eles estão consultando multidimensionale relational databasesrespectivamente. Você não pode consultar seu banco de dados relacional existente com o MDX.

A principal vantagem de usar um modelo multidimensional e usar o MDX para consultá-lo é que você está consultando dados pré-agregados e que o MDX é otimizado para consultar de maneira estatística e não relacional. Você não consulta mais linhas e tabelas para produzir um conjunto de resultados simples, mas está usando tuplas e conjuntos para fatiar e agregar um cubo multidimensional.

Pense assim: se você usar uma consulta SQL para obter o valor total das vendas de um grupo de itens específico, precisará escrever uma consulta que resuma todas as linhas da fatura de todos os itens do grupo de itens. Se você estiver usando um cubo e tiver agregações no nível do grupo de itens, o resultado será calculado durante o processamento e as agregações serão armazenadas para cada grupo de itens, tornando as consultas instantâneas.

Multidimensional e MDX é um conceito totalmente diferente do SQL baseado em conjunto relacional.

Seu exemplo pode se tornar muito mais simples, porque você faria as transformações, como a análise da data durante o processo de carregamento de dados e a comparação do último mês pode ser a calculated measure. Sua média de Seul e hoje pode sercalculated members

Se seus cubos forem bem projetados para seus requisitos, acredito que você poderia fatiar e dividir o conjunto de dados de seu exemplo sem precisar escrever consultas, mas faça isso em uma ferramenta de análise dinâmica ou outra.

Então, novamente, não há "apenas reescrevendo o SQL no MDX". Requer um pouco de conhecimento para fazer o certo e uma mentalidade diferente. Pense nos diagramas de Venn em vez dos conjuntos de resultados.

Para fornecer um exemplo usando o banco de dados adventureworks, imagine o requisito de listar o número de pedidos de vendas por cliente nas bicicletas da categoria.

Se você fez isso usando SQL, seria necessário escrever uma consulta que conte o número de pedidos de vendas que contêm uma linha com um produto que passa a pertencer à categoria bicicletas e associá-lo à tabela de clientes, para que se torne uma consulta bastante complexa .

-- 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;

No MDX (desde que seu cubo seja bem projetado para esse requisito), você pode escrever apenas porque a lógica e a complexidade foram movidas para outro lugar:

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

Os cubos / bancos de dados OLAP têm as seguintes características:

• Obtenha informações já agregadas de acordo com as necessidades do usuário.
• Acesso fácil e rápido
• Capacidade de manipular os dados agregados em diferentes dimensões
• Um cubo usa funções clássicas de agregação min, max, count, sum, avg, mas também pode usar funções específicas de agregação.

MDX versus SQL:

O MDX é criado para navegar nos bancos de dados multidimensionais e definir consultas em todos os seus objetos (dimensões, hierarquias, níveis, membros e células) para obter (simplesmente) uma representação de tabelas dinâmicas.

MDX usa muitos idêntica como palavras-chave SQL, como SELECT, FROM, WHERE. A diferença é que o SQL produz visualizações relacionais enquanto o MDX produz visualizações multidimensionais de dados .

A diferença também é vista na estrutura geral dos dois idiomas:

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

FROMespecifica a fonte de dados:
No SQL: uma ou mais tabelas
No MDX: um cubo

SELECT indica os resultados desejados para recuperar pela consulta:

No SQL:

• Uma visualização de dados em duas dimensões (linhas e colunas)
• Linhas têm a mesma estrutura definida por colunas

No MDX:

• Qualquer número de dimensões para formar os resultados da consulta.
• O termo eixo usado para evitar confusão com as dimensões do cubo.
• Não há significado especial para as linhas e colunas, mas é necessário definir cada eixo: o eixo 1 define o eixo horizontal e o eixo 2 define o eixo vertical.

Exemplo de consulta MDX:

Medidas : Preço unitário, quantidade, desconto, valor da venda, frete
Dimensão :
Hierarquia de tempo : Ano> Trimestre> Mês> com membros:

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

• Trimestre: Q1, Q2, Q3, Q4

• Mês: janeiro, fevereiro, março,…

Dimensão :
Hierarquia de clientes : Continente> País> Estado> Cidade com membros:

• Cidade: Paris, Lyon, Berlim, Köln, Marselha, Nantes…

• Estado: Loire atlantique, Bocas do Ródano, Baixo Reno, Turim…

• País: Áustria, Bélgica, Danmark, França, ...

• Nível de continente: Europa, América do Norte, América do Sul, Ásia

Dimensão :
Hierarquia do produto : Categoria> Subcategoria> produto com membros:

• Categoria: Comida, Bebida…
• Categoria de comida: Assados_comidas…
• ...

update : Este exemplo é melhor:

Objetivo da consulta: obter o valor das vendas e o número de unidades (nas colunas) de todas as famílias de produtos (nas linhas) vendidas na Califórnia durante o primeiro trimestre de 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: notas de uso do Modrian (que traduz consultas MDX para uso em bancos de dados relacionais)

Encontrei um exemplo decente, embora o SQL não seja muito mais complexo (comparado ao SaasBase em vez do MDX):

fonte: “OLAP” em tempo real para Big Data (+ casos de uso) - bigdata.ro 2013