ตัวอย่างที่ดีของ MDX vs SQL สำหรับการสืบค้นเชิงวิเคราะห์

ทุกคนสามารถแสดงให้ฉันเห็นตัวอย่างที่ดีเกี่ยวกับข้อดีของ MDX เหนือ SQL ทั่วไปเมื่อทำการสอบถามวิเคราะห์? ฉันต้องการเปรียบเทียบแบบสอบถาม MDX กับแบบสอบถาม SQL ที่ให้ผลลัพธ์ที่คล้ายกัน

Wikipedia พูดว่า :

แม้ว่ามันจะเป็นไปได้ที่จะแปลบางส่วนเหล่านี้เป็น SQL แบบดั้งเดิม แต่มันก็มักจะต้องมีการสังเคราะห์นิพจน์ SQL ที่เงอะงะแม้สำหรับ MDX ที่ง่ายมาก

แต่ไม่มีการอ้างอิงหรือตัวอย่าง ฉันตระหนักดีว่าข้อมูลพื้นฐานจะต้องมีการจัดระเบียบที่แตกต่างกันและ OLAP จะต้องการการประมวลผลและการจัดเก็บต่อการแทรกเพิ่ม (ข้อเสนอของฉันคือการย้ายจาก Oracle RDBMS ไปยังApache Kylin + Hadoop )

บริบท:ฉันพยายามโน้มน้าวใจ บริษัท ของฉันว่าเราควรทำการสืบค้นฐานข้อมูล OLAP แทนฐานข้อมูล OLTP ข้อความค้นหา SIEM ส่วนใหญ่ใช้การเรียงลำดับตามกลุ่มและการรวมกันเป็นจำนวนมาก นอกเหนือจากการเพิ่มประสิทธิภาพแล้วฉันคิดว่าข้อความค้นหา OLAP (MDX) จะกระชับและอ่าน / เขียนได้ง่ายกว่า OLTP SQL ที่เทียบเท่า ตัวอย่างที่เป็นรูปธรรมจะผลักดันจุดกลับบ้าน แต่ฉันไม่ใช่ผู้เชี่ยวชาญของ SQL ซึ่งมี MDX น้อยกว่า ...

ถ้าช่วยได้นี่คือตัวอย่างแบบสอบถาม SQL ที่เกี่ยวข้องกับ SIEM สำหรับเหตุการณ์ไฟร์วอลล์ที่เกิดขึ้นในสัปดาห์ที่ผ่านมา:

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

MDXและSQLไม่มีทางเหมือนกันและมักจะไม่เทียบเท่ากันเนื่องจากมีการสอบถามmultidimensionalและrelational databasesตามลำดับ คุณไม่สามารถสืบค้นฐานข้อมูลเชิงสัมพันธ์ที่มีอยู่ด้วย MDX

ข้อได้เปรียบหลักของการใช้โมเดลหลายมิติและการใช้ MDX ในการสืบค้นก็คือคุณกำลังทำการสืบค้นข้อมูลที่รวบรวมไว้ล่วงหน้าและ MDX นั้นได้รับการปรับให้เหมาะสมกับการสืบค้นด้วยวิธีทางสถิติแทนที่จะเป็นวิธีเชิงสัมพันธ์ คุณไม่ต้องค้นหาแถวและตารางอีกต่อไปเพื่อสร้างชุดผลลัพธ์แบบเรียบ แต่คุณใช้ tuples และชุดเพื่อฝานและรวมลูกบาศก์หลายมิติ

คิดอย่างนี้: ถ้าคุณใช้แบบสอบถาม SQL เพื่อรับยอดขายรวมสำหรับกลุ่มรายการเฉพาะคุณจะต้องเขียนแบบสอบถามที่รวมบรรทัดใบแจ้งหนี้ทั้งหมดสำหรับรายการทั้งหมดในกลุ่มรายการ หากคุณกำลังใช้คิวบ์และมีการรวมในระดับกลุ่มรายการผลลัพธ์จะถูกคำนวณในระหว่างการประมวลผลและการรวมจะถูกเก็บไว้สำหรับแต่ละกลุ่มรายการทำให้การสืบค้นทันที

Multidimensional และ MDX เป็นแนวคิดที่แตกต่างอย่างสิ้นเชิงจาก SQL แบบอิงเชิงสัมพันธ์

calculated measureตัวอย่างเช่นคุณอาจจะกลายเป็นง่ายมากเพราะคุณจะทำแปลงดังกล่าวเป็นวันที่แยกระหว่างขั้นตอนการโหลดข้อมูลของคุณและการเปรียบเทียบเดือนที่ผ่านมาของคุณอาจจะเป็น โซลของคุณโดยเฉลี่ยและวันนี้อาจเป็นcalculated members

หากคิวบ์ของคุณได้รับการออกแบบมาอย่างดีสำหรับความต้องการของคุณฉันเชื่อว่าคุณสามารถแบ่งและกำหนดชุดข้อมูลตัวอย่างของคุณโดยไม่จำเป็นต้องเขียนแบบสอบถาม แต่ทำได้ในเครื่องมือวิเคราะห์อื่น

จากนั้นอีกครั้งไม่มี "เพิ่งเขียน SQL ใหม่ใน MDX" มันต้องใช้ความรู้พอสมควรในการทำสิ่งที่ถูกต้องและความคิดที่แตกต่าง คิดว่าเวนน์ไดอะแกรมแทนที่จะเป็นชุดผลลัพธ์

เพื่อให้คุณมีตัวอย่างโดยใช้ฐานข้อมูล adventureworks ลองจินตนาการถึงความต้องการในการแสดงรายการจำนวนคำสั่งขายของลูกค้าในหมวดหมู่จักรยาน

หากคุณทำเช่นนั้นโดยใช้ SQL คุณจะต้องเขียนแบบสอบถามที่นับจำนวนคำสั่งขายที่มีบรรทัดที่มีผลิตภัณฑ์ที่เกิดขึ้นจากประเภท bikes และเข้าร่วมที่ตารางลูกค้าเพื่อที่จะกลายเป็นแบบสอบถามที่ค่อนข้างซับซ้อน .

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

ใน MDX (หากคิวบ์ของคุณได้รับการออกแบบมาอย่างดีสำหรับข้อกำหนดนี้) คุณสามารถเขียนได้เพราะตรรกะและความซับซ้อนได้ย้ายไปที่อื่น:

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

OLAP คิวบ์ / ฐานข้อมูลมีคุณสมบัติดังต่อไปนี้:

• รับข้อมูลที่รวบรวมไว้แล้วตามความต้องการของผู้ใช้
• เข้าถึงได้ง่ายและรวดเร็ว
• ความสามารถในการจัดการข้อมูลรวมในมิติต่างๆ
• คิวบ์ใช้ฟังก์ชันการรวมแบบคลาสสิก min, max, count, sum, avg, แต่ยังสามารถใช้ฟังก์ชันการรวมที่เจาะจงได้

MDX กับ SQL:

MDX ถูกสร้างขึ้นเพื่อนำทางฐานข้อมูลหลายมิติและเพื่อกำหนดแบบสอบถามบนวัตถุทั้งหมดของพวกเขา (มิติ, ลำดับชั้น, ระดับ, สมาชิกและเซลล์) เพื่อรับ (เพียง) แสดงถึงตารางสาระสำคัญ

MDX ใช้หลายที่เหมือนกันเป็นคำหลัก SQL เช่นSELECT, ,FROM WHEREความแตกต่างคือ SQL ผลิตมุมมองเชิงสัมพันธ์ในขณะที่ MDX ผลิตมุมมองหลายมิติของข้อมูล

ความแตกต่างก็เห็นได้ในโครงสร้างทั่วไปของทั้งสองภาษา:

แบบสอบถาม SQL: SELECT column1, column2, ..., column FROM table
แบบสอบถาม MDX:SELECT axis1 ON COLUMNS, axis2 ON ROWS FROM cube

FROMระบุแหล่งข้อมูล:
ใน SQL: หนึ่งตารางขึ้นไป
ใน MDX: a cube

SELECT ระบุผลลัพธ์ที่ต้องการกู้คืนโดยการสืบค้น:

ใน SQL:

• ข้อมูลการดูในสองมิติ (แถวและคอลัมน์)
• แถวมีโครงสร้างเดียวกันที่กำหนดโดยคอลัมน์

ใน MDX:

• จำนวนส่วนข้อมูลใด ๆ เพื่อสร้างผลลัพธ์แบบสอบถาม
• แกนคำที่ใช้เพื่อหลีกเลี่ยงความสับสนกับมิติของลูกบาศก์
• ไม่มีความหมายพิเศษสำหรับแถวและคอลัมน์ แต่คุณต้องกำหนดแต่ละแกน: axe1 กำหนดแกนนอนและแกน 2 กำหนดแกนแนวตั้ง

ตัวอย่างแบบสอบถาม MDX:

มาตรการ : ราคาต่อหน่วย, ปริมาณ, ส่วนลด, ยอดขาย,
มิติการขนส่ง:
ลำดับชั้นเวลา: ปี> ไตรมาส> เดือน> กับสมาชิก:

• ปี: 2010, 2011, 2012, 2013, 2014

• ไตรมาส: Q1, Q2, Q3, Q4

• เดือน: มกราคม, กุมภาพันธ์, มีนาคม, ...

มิติข้อมูล :
ลำดับชั้นลูกค้า: ทวีป> ประเทศ> รัฐ> เมืองพร้อมสมาชิก:

• เมือง: Paris, Lyon, Berlin, Köln, Marseille, Nantes …

• รัฐ: Loire atlantique, Bouches du Rhône, Bas Rhin, ตูริน…

• ประเทศ: ออสเตรีย, เบลเยี่ยม, Danmark, ฝรั่งเศส, ...

• ระดับทวีป: ยุโรปอเมริกาเหนืออเมริกาเหนืออเมริกาเอเชีย

มิติข้อมูล :
ลำดับชั้นผลิตภัณฑ์: หมวดหมู่> หมวดหมู่ย่อย> ผลิตภัณฑ์ที่มีสมาชิก:

• หมวดหมู่: อาหาร, เครื่องดื่ม ...
• หมวดหมู่อาหาร: Baked_food ...
• ...

ปรับปรุง : ตัวอย่างนี้ดีกว่า:

เป้าหมายการค้นหา: รับยอดขายและจำนวนหน่วย (ในคอลัมน์) ของตระกูลผลิตภัณฑ์ทั้งหมด (แถว) ขายในแคลิฟอร์เนียในช่วงไตรมาสที่ 1 ของปี 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

แหล่งที่มา: บันทึกการใช้งานสำหรับ Modrian (ซึ่งแปลแบบสอบถาม MDX เพื่อใช้กับฐานข้อมูลเชิงสัมพันธ์)

ฉันพบตัวอย่างที่ดีแม้ว่า SQL จะไม่ซับซ้อนกว่านี้มาก (เทียบกับ SaasBase แทนที่จะเป็น MDX):

แหล่งที่มา: เรียลไทม์“ OLAP” สำหรับ Big Data (+ ใช้เคส) - bigdata.ro 2013