분석 쿼리를위한 MDX vs SQL의 좋은 예

누구든지 분석 쿼리를 수행 할 때 일반 SQL에 비해 MDX의 장점에 대한 좋은 예를 보여줄 수 있습니까? MDX 쿼리와 비슷한 결과를 제공하는 SQL 쿼리를 비교하고 싶습니다.

위키 백과는 말합니다 :

이들 중 일부를 기존 SQL로 변환 할 수는 있지만 매우 간단한 MDX 식의 경우에도 서투른 SQL 식의 합성이 필요한 경우가 많습니다.

그러나 인용이나 예는 없습니다. 기본 데이터를 다르게 구성해야한다는 것을 잘 알고 있으며 OLAP에는 인서트 당 더 많은 처리 및 저장이 필요합니다. (제 제안은 Oracle RDBMS에서 Apache Kylin + Hadoop으로 이동하는 것입니다 )

컨텍스트 : 회사에 OLTP 데이터베이스 대신 OLAP 데이터베이스를 쿼리해야한다고 설득하려고합니다. 대부분의 SIEM 쿼리는 그룹 별, 정렬 및 집계를 많이 사용합니다. 성능 향상 외에도 OLAP (MDX) 쿼리는 동등한 OLTP SQL보다 더 간결하고 읽기 / 쓰기가 더 쉽다고 생각합니다. 구체적인 예는 요점을 이끌어 낼 것이지만 SQL의 전문가는 아니지만 MDX는 훨씬 적습니다 ...

도움이되는 경우 지난 주에 발생한 방화벽 이벤트에 대한 샘플 SIEM 관련 SQL 쿼리는 다음과 같습니다.

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가 관계형 방식이 아닌 통계적인 방식으로 쿼리하도록 최적화되어 있다는 것입니다. 더 이상 플랫 결과 세트를 생성하기 위해 행과 테이블을 쿼리하지 않지만 튜플과 세트를 사용하여 다차원 큐브를 슬라이스 및 집계합니다.

SQL 쿼리를 사용하여 특정 품목 그룹의 총 판매액을 얻으려면 품목 그룹의 모든 품목에 대한 모든 송장 라인을 요약하는 조회를 작성해야합니다. 큐브를 사용 중이고 항목 그룹 레벨에서 집계가있는 경우 처리 중에 결과가 계산되고 각 항목 그룹에 대해 집계가 저장되어 쿼리가 즉시 이루어집니다.

다차원 및 MDX는 관계형 집합 기반 SQL과는 완전히 다른 개념입니다.

데이터로드 프로세스 중 날짜 구문 분석과 같은 변환을 수행하고 지난 달 비교가 일 수 있기 때문에 예제가 훨씬 단순해질 수 있습니다 calculated measure. 서울 평균과 오늘은calculated members

큐브가 요구 사항에 맞게 설계되면 쿼리를 작성하지 않고도 예제 데이터 세트를 슬라이스하고 다이 싱 할 수 있지만 피벗 가능 또는 다른 분석 도구에서 수행 할 수 있다고 생각합니다.

그런 다음 다시 "MDX에서 SQL을 다시 쓰는 것"은 없습니다. 올바르게하고 다른 사고 방식을 위해서는 상당한 지식이 필요합니다. 결과 집합 대신 벤 다이어그램을 생각하십시오.

adventureworks 데이터베이스를 사용하여 예제를 제공하려면 자전거 카테고리에서 고객 별 판매 주문 수를 나열해야한다는 것을 상상해보십시오.

SQL을 사용하여 수행 한 경우 자전거 카테고리 인 제품이있는 라인이 포함 된 판매 주문 수를 계산하고 customers 테이블에 조인하는 쿼리를 작성해야하므로 상당히 복잡한 쿼리가됩니다. .

-- 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 : 큐브

SELECT 쿼리로 복구하려는 결과를 나타냅니다.

SQL에서 :

• 2 차원 (행 및 열)의 뷰 데이터
• 행은 열에 의해 정의 된 동일한 구조를가집니다

MDX에서 :

• 쿼리 결과를 구성 할 차원 수
• 큐브 차원과 혼동을 피하기 위해 사용되는 축이라는 용어입니다.
• 행과 열에 특별한 의미는 없지만 각 축을 정의해야합니다. axe1은 가로 축을 정의하고 축 2는 세로 축을 정의합니다.

MDX 쿼리 예 :

측정 : 단가, 수량, 할인, 판매액,화물
치수 : 시간
계층 구조 : 연도> 분기> 월> 멤버 포함 :

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

• 분기 : Q1, Q2, Q3, Q4

• 월 : 1 월, 2 월, 3 월…

차원 : 고객
계층 구조 : 대륙> 국가> 주> 회원과 도시 :

• 도시 : 파리, 리옹, 베를린, 쾰른, 마르세유, 낭트…

• 주 : 루 아르 아틀란 티크, Bouches du Rhône, Bas Rhin, Torino…

• 국가 : 오스트리아, 벨기에, 덴마크, 프랑스 등 ...

• 대륙 수준 : 유럽, 북미, Sud America, 아시아

차원 : 제품
계층 구조 : 범주> 하위 범주> 멤버가있는 제품 :

• 카테고리 : 음식, 음료…
• 음식 카테고리 : Baked_food…
• …

업데이트 :이 예제가 더 좋습니다 :

쿼리 목표 : 2010 년 1 분기 동안 캘리포니아에서 판매 된 모든 제품군 (행)의 판매량 및 단위 (열)를 가져옵니다.

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이 그렇게 복잡하지는 않지만 (MDX 대신 SaasBase와 비교할 때) 괜찮은 예를 찾았습니다.

출처 : 빅 데이터 용 실시간“OLAP”(+ 사용 사례)-bigdata.ro 2013