Buen ejemplo de MDX vs SQL para consultas analíticas

¿Alguien puede mostrarme un buen ejemplo de las ventajas de MDX sobre SQL normal al hacer consultas analíticas? Me gustaría comparar una consulta MDX con una consulta SQL que dé resultados similares.

Wikipedia dice :

Si bien es posible traducir algunos de estos al SQL tradicional, con frecuencia requeriría la síntesis de expresiones SQL torpes incluso para expresiones MDX muy simples.

Pero no hay ni una cita ni un ejemplo. Soy plenamente consciente de que los datos subyacentes deben organizarse de manera diferente, y OLAP requerirá más procesamiento y almacenamiento por inserción. (Mi propuesta es pasar de un RDBMS de Oracle a Apache Kylin + Hadoop )

Contexto: estoy tratando de convencer a mi empresa de que deberíamos consultar una base de datos OLAP en lugar de una base de datos OLTP. La mayoría de las consultas SIEM hacen un uso intensivo de agrupar, ordenar y agregar. Además del aumento de rendimiento, creo que las consultas OLAP (MDX) serían más concisas y más fáciles de leer / escribir que el SQL OLTP equivalente. Un ejemplo concreto llevaría el punto a casa, pero no soy un experto en SQL, mucho menos MDX ...

Si ayuda, aquí hay una consulta SQL de muestra relacionada con SIEM para eventos de firewall que ocurrieron la semana pasada:

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

MDXy SQLde ninguna manera son iguales, y a menudo ni siquiera son comparables, ya que están consultando multidimensionaly relational databasesrespectivamente. No puede consultar su base de datos relacional existente con MDX.

La principal ventaja de usar un modelo multidimensional y usar MDX para consultarlo es que está consultando datos agregados previamente y que MDX está optimizado para consultar de manera estadística en lugar de relacional. Ya no consulta filas y tablas para producir un conjunto de resultados plano, pero está utilizando tuplas y conjuntos para cortar y agregar un cubo multidimensional.

Piénselo de esta manera: si usa una consulta SQL para obtener el monto total de ventas para un grupo de artículos en particular, necesitaría escribir una consulta que resuma todas las líneas de factura para todos los artículos en el grupo de artículos. Si está utilizando un cubo y tiene agregaciones en el nivel del grupo de elementos, el resultado se calcula durante el procesamiento y las agregaciones se almacenan para cada grupo de elementos, lo que hace que las consultas sean instantáneas.

Multidimensional y MDX es un concepto completamente diferente del SQL relacional basado en conjuntos.

Su ejemplo podría ser mucho más simple porque estaría haciendo las transformaciones, como el análisis de fechas durante el proceso de carga de datos, y su comparación del último mes podría ser a calculated measure. Tu promedio de Seúl y hoy podría sercalculated members

Si sus cubos están bien diseñados para sus requisitos, creo que podría estar cortando y cortando en cubitos el conjunto de datos de su ejemplo sin necesidad de escribir consultas, sino hacerlo en una herramienta de análisis pivotante u otra herramienta de análisis.

Por otra parte, no hay "solo reescribir SQL en MDX". Se requiere un poco de conocimiento para hacerlo bien y una mentalidad diferente. Piense en diagramas de Venn en lugar de conjuntos de resultados.

Para proporcionarle un ejemplo con la base de datos de Adventureworks, imagine el requisito de enumerar el número de pedidos de cliente por cliente en la categoría de bicicletas.

Si hiciera eso usando SQL, necesitaría escribir una consulta que cuente el número de pedidos de ventas que contienen una línea con un producto que resulta ser de la categoría de bicicletas y unir eso a la tabla de clientes, para que se convierta en una consulta bastante compleja .

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

En MDX (siempre que su cubo esté bien diseñado para este requisito) simplemente podría escribir porque la lógica y la complejidad se han trasladado a otro lado:

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

Los cubos / bases de datos OLAP tienen las siguientes características:

• Obtenga información ya agregada de acuerdo con las necesidades del usuario.
• Acceso fácil y rápido.
• Capacidad para manipular los datos agregados en diferentes dimensiones.
• Un cubo usa funciones de agregación clásicas min, max, count, sum, avg, pero también puede usar funciones de agregación específicas.

MDX versus SQL:

MDX está hecho para navegar por las bases de datos multidimensionales y para definir consultas en todos sus objetos (dimensiones, jerarquías, niveles, miembros y celdas) para obtener (simplemente) una representación de tablas dinámicas.

MDX utiliza muchos idéntica como palabras clave de SQL, como SELECT, FROM, WHERE. La diferencia es que SQL produce vistas relacionales, mientras que MDX produce vistas multidimensionales de datos .

La diferencia también se ve en la estructura general de los dos idiomas:

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

FROMespecifica la fuente de datos:
en SQL: una o más tablas
en MDX: un cubo

SELECT indica los resultados que desea recuperar mediante la consulta:

En SQL:

• Una vista de datos en dos dimensiones (filas y columnas)
• Las filas tienen la misma estructura definida por columnas

En MDX:

• Cualquier cantidad de dimensiones para formar los resultados de la consulta.
• El término eje utilizado para evitar confusiones con las dimensiones del cubo.
• No tiene un significado especial para las filas y columnas, pero debe definir cada eje: axe1 define el eje horizontal y el eje 2 define el eje vertical.

Ejemplo de consulta MDX:

Medidas : Precio unitario, Cantidad, Descuento, Monto de ventas,
Dimensión de flete :
Jerarquía de tiempo : Año> Trimestre> Mes> con miembros:

• Año: 2010, 2011, 2012, 2013, 2014

• Trimestre: Q1, Q2, Q3, Q4

• Mes: enero, febrero, marzo, ...

Dimensión :
Jerarquía del cliente : Continente> País> Estado> Ciudad con miembros:

• Ciudad: París, Lyon, Berlín, Colonia, Marsella, Nantes ...

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

• País: Austria, Bélgica, Dinamarca, Francia, ...

• Nivel continente: Europa, América del Norte, América del Sur, Asia

Dimensión :
Jerarquía del producto : Categoría> Subcategoría> producto con miembros:

• Categoría: Comida, Bebida ...
• Categoría de alimentos: alimentos horneados ...
• ...

actualización : este ejemplo es mejor:

Objetivo de consulta: obtener la cantidad de ventas y el número de unidades (en columnas) de todas las familias de productos (en filas) vendidas en California durante el primer 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

fuente: Notas de uso para Modrian (que traduce consultas MDX para su uso en bases de datos relacionales)

Encontré un ejemplo decente, aunque el SQL no es mucho más complejo (en comparación con SaasBase en lugar de MDX):

fuente: "OLAP" en tiempo real para Big Data (+ casos de uso) - bigdata.ro 2013