Bon exemple de MDX vs SQL pour les requêtes analytiques

Quelqu'un peut-il me montrer un bon exemple des avantages de MDX par rapport à SQL standard lors de l'exécution de requêtes analytiques? Je voudrais comparer une requête MDX avec une requête SQL qui donne des résultats similaires.

Wikipédia dit :

Bien qu'il soit possible de traduire certains d'entre eux en SQL traditionnel, cela nécessiterait fréquemment la synthèse d'expressions SQL maladroites même pour des expressions MDX très simples.

Mais il n'y a ni citation ni exemple. Je suis pleinement conscient que les données sous-jacentes doivent être organisées différemment et OLAP nécessitera plus de traitement et de stockage par insertion. (Ma proposition est de passer d'un SGBDR Oracle à Apache Kylin + Hadoop )

Contexte: J'essaie de convaincre mon entreprise que nous devrions interroger une base de données OLAP au lieu d'une base de données OLTP. La plupart des requêtes SIEM font un usage intensif du regroupement, du tri et de l'agrégation. Outre l'amélioration des performances, je pense que les requêtes OLAP (MDX) seraient plus concises et plus faciles à lire / écrire que l'équivalent OLTP SQL. Un exemple concret nous ramènerait au but, mais je ne suis pas un expert en SQL, encore moins en MDX ...

Si cela peut vous aider, voici un exemple de requête SQL liée à SIEM pour les événements de pare-feu qui se sont produits la semaine dernière:

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

MDXet ne SQLsont en aucun cas les mêmes, et souvent même pas comparables, car ils interrogent multidimensionalet relational databasesrespectivement. Vous ne pouvez pas interroger votre base de données relationnelle existante avec MDX.

Le principal avantage de l'utilisation d'un modèle multidimensionnel et de l'utilisation de MDX pour l'interroger est que vous interrogez des données pré-agrégées et que MDX est optimisé pour interroger de manière statistique plutôt que relationnelle. Vous n'interrogez plus les lignes et les tables pour produire un ensemble de résultats plat, mais vous utilisez des tuples et des ensembles pour découper et agréger un cube multidimensionnel.

Considérez-le comme ceci: si vous utilisez une requête SQL pour obtenir le montant total des ventes pour un groupe d'articles particulier, vous devez écrire une requête qui résume toutes les lignes de facture pour tous les articles du groupe d'articles. Si vous utilisez un cube et que vous avez des agrégations au niveau du groupe d'articles, le résultat est calculé pendant le traitement et les agrégations sont stockées pour chaque groupe d'articles, ce qui rend les requêtes instantanées.

Multidimensionnel et MDX est un concept entièrement différent du SQL basé sur un ensemble relationnel.

Votre exemple pourrait devenir beaucoup plus simple car vous effectueriez des transformations telles que l'analyse de la date pendant votre processus de chargement de données et votre comparaison du dernier mois pourrait être a calculated measure. Votre moyenne de Séoul et aujourd'hui pourrait êtrecalculated members

Si vos cubes sont bien conçus pour vos besoins, je pense que vous pourriez découper et découper l'ensemble de données de votre exemple sans même avoir besoin d'écrire des requêtes, mais faites-le dans un outil d'analyse pivotant ou autre.

Là encore, il n'y a pas de "réécriture de SQL dans MDX". Il faut un peu de connaissances pour bien faire les choses et un état d'esprit différent. Pensez aux diagrammes de Venn plutôt qu'aux ensembles de résultats.

Pour vous donner un exemple d'utilisation de la base de données adventureworks, imaginez l'exigence de lister le nombre de commandes client par client dans la catégorie vélos.

Si vous faisiez cela en utilisant SQL, vous auriez besoin d'écrire une requête qui compte le nombre de commandes client contenant une ligne avec un produit qui se trouve être de la catégorie vélos et de le joindre à la table des clients, de sorte que cela deviendrait une requête assez complexe .

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

Dans MDX (à condition que votre cube soit bien conçu pour cette exigence), vous pouvez simplement écrire car la logique et la complexité ont évolué ailleurs:

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

Les cubes / bases de données OLAP ont les caractéristiques suivantes:

• Obtenez des informations déjà agrégées selon les besoins de l'utilisateur.
• Accès facile et rapide
• Capacité à manipuler les données agrégées dans différentes dimensions
• Un cube utilise des fonctions d'agrégation classiques min, max, count, sum, avg, mais peut également utiliser des fonctions d'agrégation spécifiques.

MDX contre SQL:

MDX est fait pour naviguer dans les bases de données multidimensionnelles et pour définir des requêtes sur tous leurs objets (dimensions, hiérarchies, niveaux, membres et cellules) pour obtenir (simplement) une représentation des tableaux croisés dynamiques.

MDX utilise beaucoup identiques comme mots - clés SQL, comme SELECT, FROM, WHERE. La différence est que SQL produit des vues relationnelles tandis que MDX produit des vues multidimensionnelles des données .

La différence est également visible dans la structure générale des deux langues:

Requête SQL: SELECT column1, column2, ..., column FROM table
requête MDX:SELECT axis1 ON COLUMNS, axis2 ON ROWS FROM cube

FROMspécifie la source de données:
En SQL: une ou plusieurs tables
En MDX: un cube

SELECT indique les résultats que l'on souhaite récupérer par la requête:

En SQL:

• Une vue des données en deux dimensions (lignes et colonnes)
• Les lignes ont la même structure définie par des colonnes

Dans MDX:

• N'importe quel nombre de dimensions pour former les résultats de la requête.
• Le terme axe utilisé pour éviter toute confusion avec les dimensions du cube.
• Aucune signification particulière pour les lignes et les colonnes, mais vous devez définir chaque axe: axe1 définit l'axe horizontal et axe 2 définit l'axe vertical.

Exemple de requête MDX:

Mesures : Prix unitaire, Quantité, Remise, Montant des ventes, Fret
Dimension :
Hiérarchie temporelle : Année> Trimestre> Mois> avec les membres:

• Année: 2010, 2011, 2012, 2013, 2014

• Trimestre: Q1, Q2, Q3, Q4

• Mois: janvier, février, mars,…

Dimension :
Hiérarchie client : Continent> Pays> État> Ville avec membres:

• Ville: Paris, Lyon, Berlin, Cologne, Marseille, Nantes…

• Etat: Loire atlantique, Bouches du Rhône, Bas Rhin, Torino…

• Pays: Autriche, Belgique, Danmark, France, ...

• Niveau du continent: Europe, Amérique du Nord, Amérique du Sud, Asie

Dimension :
Hiérarchie des produits : catégorie> sous-catégorie> produit avec membres:

• Catégorie: Nourriture, boisson…
• Catégorie de nourriture: Baked_food…
• …

mise à jour : Cet exemple est meilleur:

Objectif de la requête: obtenir le montant des ventes et le nombre d'unités (sur les colonnes) de toutes les familles de produits (sur les lignes) vendues en Californie au premier trimestre 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

source: Notes d'utilisation pour Modrian (qui traduit les requêtes MDX pour une utilisation sur les bases de données relationnelles)

J'ai trouvé un bon exemple, bien que le SQL ne soit pas beaucoup plus complexe (par rapport à SaasBase au lieu de MDX):

source: «OLAP» en temps réel pour le Big Data (+ cas d'utilisation) - bigdata.ro 2013