1 대형차원이란?

2 고려사항

3 사례

4 결론

대형차원은 말 그대로 큰 차원 테이블을 말한다. 크다는 것은 다음과 같은 2가지를 말한다.

• 테이블에 row수가 많다.
  
• 테이블에 column수가 많다.
  
  

일반적으로 고객과 같은 차원이 대형차원에 속한다. 일반적으로 대형차원은 몇 천만 건 정도 된다. 차원이 팩트처럼 크기 때문에 차원과는 또 다른 처리가 필요하다. 주로 Outrigger 라고 불리우는 보조테이블을 이용하거나 수직분할하여 대형차원 크기를 줄여서 적은 양의 I/O로 요구사항을 처리할 수 있게 하는 것이 핵심이다. 스노우플레이크 스키마로 만드는 것도 기본 컨셉은 차원의 슬림화이다.

• 제약 없는 차원들의 브라우즈 성능, 특히 속성들의 개수가 작은 경우에도
  
• 차원 속성들의 교차-제약을 갖는 값들을 가져오는 시간
  
• 대형 차원이 사용되어져야 할 필요가 있을 경우 사실 테이블 질의에서 비효율성
  
• SCD Type2의 추가적인 행들
  
• 다수의 계층구조를 가짐
  

가장 대표적인 대형차원인 고객으로 설명하겠다. Outrigger의 그림을 이용해서 좀 더 구체화 해보자.

실제로 슬림하게 만들기 전(위 그림에서 좌측)의 고객 데이터는 다음과 같은 모양일 것이다.

단순하게 계산하면

• 고객수 2천만
  
• 각 컬럼의 크기(byte)는 최대 248, 이메일, 거주지역의 길이를 평균으로 치면 - 100, Row당 150byte 정도로 계산하면..
  
  • 고객키 = 4
    
  • 고객ID = 12
    
  • 고객명 = 30
    
  • 핸드폰 = 13
    
  • 이메일 = 100
    
  • 성별 = 2
    
  • 생년월일 = 8
    
  • 우편번호 = 7
    
  • 거주지역 = 100
    
  • 고객등급 = 8
    
• 순수한 데이터 크기만 150 * 20000000 / 1024 / 1024 = 2861.02 MB --> 최소한이다.
  
  

슬림하게 만든다면 우편번호와 고객등급은 코드화 하고, 핸드폰, 이메일과 같은 연락처는 활용도가 떨어지므로 수직분할 한다면 실제로 다음과 같은 모양이 될 것이다. 성별도 2byte 문자가 아닌 bit형태로 바꾸고 생년월일을 숫자로 바꾸면 더욱 좋다.

그러면, 대략

• 고객키 = 4
  
• 고객ID = 12
  
• 고객명 = 30
  
• 성별 = 1
  
• 생년월일 = 4
  
• 우편번호키 = 4
  
• 고객등급키 = 1
  
• Row당 56byte이고 56 * 20000000 / 1024 / 1024 = 1068.12 MB 이므로 대략 2.5배로 크기가 줄었다. 많이 슬림해졌다.
  
  

대형차원에 대한 고려사항은 모두 성능과 관련된 내용이다. 차원의 크기가 크면 여러가지로 성능상 불이익을 가져오기 때문에 최대한 슬림하게 유지하는 것이 중요하다. 테이블의 크기가 작아지는 어떤 방법이든 상관없다. 대형차원은 무조건 슬림한 것이 좋다. 단, 슬림의 기준은 데이터의 활용 패턴과 업무 요구사항에 따르게 된다.