Gutes Beispiel für MDX vs SQL für analytische Abfragen

Kann mir jemand ein gutes Beispiel für die Vorteile von MDX gegenüber regulärem SQL bei analytischen Abfragen zeigen? Ich möchte eine MDX-Abfrage mit einer SQL-Abfrage vergleichen, die ähnliche Ergebnisse liefert.

Wikipedia sagt :

Während es möglich ist, einige davon in traditionelles SQL zu übersetzen, würde es häufig die Synthese von ungeschickten SQL-Ausdrücken erfordern, selbst für sehr einfache MDX-Ausdrücke.

Aber es gibt weder ein Zitat noch ein Beispiel. Ich bin mir völlig bewusst, dass die zugrunde liegenden Daten anders organisiert sein müssen und OLAP mehr Verarbeitung und Speicherung pro Einfügung erfordert. (Mein Vorschlag ist, von einem Oracle RDBMS zu Apache Kylin + Hadoop zu wechseln. )

Kontext: Ich versuche mein Unternehmen davon zu überzeugen, dass wir eine OLAP-Datenbank anstelle einer OLTP-Datenbank abfragen sollten. Die meisten SIEM-Abfragen verwenden häufig Gruppierung, Sortierung und Aggregation. Neben der Leistungssteigerung denke ich, dass OLAP (MDX) -Anfragen präziser und einfacher zu lesen / schreiben sind als das entsprechende OLTP-SQL. Ein konkretes Beispiel würde den Punkt nach Hause bringen, aber ich bin kein SQL-Experte, geschweige denn MDX ...

Wenn dies hilfreich ist, finden Sie hier ein Beispiel für eine SIEM-bezogene SQL-Abfrage für Firewall-Ereignisse, die in der letzten Woche aufgetreten sind:

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

MDXund SQLsind in keiner Weise die gleichen, und oft nicht einmal vergleichbar, da sie abfragen multidimensionalund relational databasesjeweils. Sie können Ihre vorhandene relationale Datenbank nicht mit MDX abfragen.

Der Hauptvorteil der Verwendung eines mehrdimensionalen Modells und der Verwendung von MDX zum Abfragen besteht darin, dass Sie voraggregierte Daten abfragen und MDX für die statistische und nicht für die relationale Abfrage optimiert ist. Sie fragen keine Zeilen und Tabellen mehr ab, um eine flache Ergebnismenge zu erstellen, sondern verwenden Tupel und Mengen, um einen mehrdimensionalen Würfel zu schneiden und zu aggregieren.

Stellen Sie sich das so vor: Wenn Sie eine SQL-Abfrage verwenden, um den Gesamtumsatz für eine bestimmte Artikelgruppe abzurufen, müssen Sie eine Abfrage schreiben, die alle Rechnungszeilen für alle Artikel in der Artikelgruppe zusammenfasst. Wenn Sie einen Cube verwenden und Aggregationen auf Artikelgruppenebene haben, wird das Ergebnis während der Verarbeitung berechnet und die Aggregationen werden für jede Artikelgruppe gespeichert, sodass Abfragen sofort ausgeführt werden.

Multidimensional und MDX ist ein völlig anderes Konzept als relationales satzbasiertes SQL.

Ihr Beispiel wird möglicherweise viel einfacher, da Sie die Transformationen wie das Parsen des Datums während des Ladevorgangs durchführen und Ihr Vergleich im letzten Monat möglicherweise ein calculated measure. Ihr seoul Durchschnitt und heute könnte seincalculated members

Wenn Ihre Cubes für Ihre Anforderungen gut ausgelegt sind, könnten Sie den Datensatz Ihres Beispiels in Scheiben schneiden und in Würfel schneiden, ohne Abfragen schreiben zu müssen, aber dies in einem schwenkbaren oder einem anderen Analysetool.

Andererseits gibt es kein "nur das Umschreiben von SQL in MDX". Es erfordert einiges an Wissen, um es richtig zu machen, und eine andere Denkweise. Denken Sie an Venn-Diagramme statt an Ergebnismengen.

Stellen Sie sich vor, Sie müssen die Anzahl der Kundenaufträge nach Kunden in der Kategorie Fahrräder auflisten, um ein Beispiel für die Verwendung der Adventureworks-Datenbank zu erhalten.

Wenn Sie dies mit SQL tun würden, müssten Sie eine Abfrage schreiben, die die Anzahl der Kundenaufträge zählt, die eine Zeile mit einem Produkt enthalten, das zufällig zur Kategorie Fahrräder gehört, und diese mit der Kundentabelle verknüpfen, sodass dies zu einer ziemlich komplexen Abfrage wird .

-- 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 (vorausgesetzt, Ihr Cube ist für diese Anforderung gut ausgelegt) können Sie einfach schreiben, da sich die Logik und Komplexität an eine andere Stelle verschoben hat:

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

OLAP-Cubes / -Datenbanken weisen die folgenden Merkmale auf:

• Erhalten Sie bereits aggregierte Informationen entsprechend den Anforderungen des Benutzers.
• Einfacher und schneller Zugang
• Möglichkeit, die aggregierten Daten in verschiedenen Dimensionen zu bearbeiten
• Ein Cube verwendet die klassischen Aggregationsfunktionen min, max, count, sum, avg, kann aber auch bestimmte Aggregationsfunktionen verwenden.

MDX versus SQL:

MDX dient zum Navigieren in den mehrdimensionalen Datenbanken und zum Definieren von Abfragen für alle ihre Objekte (Dimensionen, Hierarchien, Ebenen, Elemente und Zellen), um (einfach) eine Darstellung von Pivot-Tabellen zu erhalten.

MDX verwendet viele identisch wie SQL - Schlüsselwörter, wie SELECT, FROM, WHERE. Der Unterschied besteht darin, dass SQL relationale Ansichten erzeugt, während MDX mehrdimensionale Ansichten von Daten erzeugt .

Der Unterschied zeigt sich auch in der allgemeinen Struktur der beiden Sprachen:

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

FROMGibt die Datenquelle an:
In SQL: eine oder mehrere Tabellen
In MDX: ein Cube

SELECT gibt die Ergebnisse an, die von der Abfrage wiederhergestellt werden sollen:

In SQL:

• Eine Ansicht Daten in zwei Dimensionen (Zeilen und Spalten)
• Zeilen haben dieselbe Struktur, die durch Spalten definiert ist

In MDX:

• Beliebig viele Dimensionen, um die Abfrageergebnisse zu bilden.
• Der Begriff Achse wird verwendet, um Verwechslungen mit den Würfelabmessungen zu vermeiden.
• Keine besondere Bedeutung für die Zeilen und Spalten, aber Sie müssen jede Achse definieren: Achse1 definiert die horizontale Achse und Achse 2 definiert die vertikale Achse.

Beispiel für eine MDX-Abfrage:

Maßnahmen : Einzelpreis, Menge, Rabatt, SalesAmount, Fracht
Dimension : Zeit
Hierarchie : Jahr> Quarter> Monat> mit Mitgliedern:

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

• Quartal: Q1, Q2, Q3, Q4

• Monat: Januar, Februar, März,…

Dimension :
Kundenhierarchie : Kontinent> Land> Staat> Stadt mit Mitgliedern:

• Stadt: Paris, Lyon, Berlin, Köln, Marseille, Nantes…

• Bundesland: Loire atlantique, Bouches du Rhône, Bas Rhin, Turin…

• Land: Österreich, Belgien, Dänemark, Frankreich, ...

• Kontinentalebene: Europa, Nordamerika, Südamerika, Asien

Dimension :
Produkthierarchie : Kategorie> Unterkategorie> Produkt mit Mitgliedern:

• Kategorie: Essen, Trinken…
• Lebensmittelkategorie: Baked_food…
• …

Update : Dieses Beispiel ist besser:

Abfrageziel: Ermitteln Sie die Verkaufsmenge und die Anzahl der Einheiten (in Spalten) aller Produktfamilien (in Zeilen), die im ersten Quartal 2010 in Kalifornien verkauft wurden

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

Quelle: Verwendungshinweise für Modrian (das MDX-Abfragen zur Verwendung in relationalen Datenbanken übersetzt)

Ich habe ein anständiges Beispiel gefunden, obwohl SQL nicht viel komplexer ist (im Vergleich zu SaasBase anstelle von MDX):

Quelle: Echtzeit-OLAP für Big Data (+ Anwendungsfälle) - bigdata.ro 2013