SQLD 2-5 ] 데이터베이스 구조와 성능

❏  슈퍼타입 / 서브타입 모델의 성능고려 방법

 

 1. 슈퍼타입 / 서브타입 ?

   - 데이터의 특징을 공통점과 차이점의 특징을 고려하여 효과적으로 표현.

     공통의 부분을 슈퍼타입, 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성은 서브엔터티로 구분.

     ( 학생 은 학부생과 대학원생 으로 나뉜다. 여기서 학생은 슈퍼타입, 학부생과 대학원생은 서브타입이라고 한다..) 

 

     예로 다음과 같다.

     1. 트랜잭션은 항상 일괄로 처리하는데, 테이블은 개별로 유지되어 Union 연산에 의해 성능이 저하될 수 있다.

     2. 트랜잭션은 항상 서브타입 개별로 처리하는데. 테이블은 또 하나로 되있어서.. 불필요하게 많은 양의 데이터를 읽어와야되서 성능이 저하되는 경우가 있다.

     3. 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데. 또 개별로 유지되어있거나. 하나의 테이블로 집약되어 있어서 성능이 저하되는 경우가 있다.

 

 2. 슈퍼타입 / 서브타입 데이터 모델의 변환

   

(왼쪽껀 학생(슈퍼)과 밑에 3개 학부생/대학원생(서브) 로 보면 이해되는데 오른쪽은..??)

 

슈퍼/서브 타입에 대한 변환을 잘못 설정하면 성능이 저하되는 이유는, 트랜잭션 특성을 고려 안하고 테이블을 설계했기때문

슈퍼/서브 타입을 고려한 모델로 변환하는 것의 기준은 '테이블에 발생되는 트랜잭션의 유형' 에 따라 결정.

 

* 트랜잭션 : 데이터를 처리하는 하나의 작업단위 (트랜잭션 내에 묶인 작업들은 반드시 완전히 수행되거나, 모두 수행되지 않거나)

 

 3. 슈퍼타입 / 서브타입 데이터 모델의 변환기술

   - 데이터양이 10만건도 안될정도로 적다면 그냥 전체를 하나의 테이블로 묶어도 되고..

     그렇다면.. 언제 슈퍼타입/서브타입을 적용해야될까? 

  

 3-1. 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성

    

   

 

밑에 슈퍼타입테이블에서 당사자 정보를 조회하고, 거기에 따라 서브타입인 세부적인 정보들(이해관계인,매수인,대리인)에

대한 내용을 조회하는 형식이다. 

 

그냥 평범한 프로세스? 같은데..? 1:1 관계의 형태이다. 

 

 3-2. 슈퍼타입+서브타입 트랜잭션  =>  슈퍼타입+서브타입 테이블로 만들자

   - 슈퍼타입+서브타입이 모두 하나의 테이블로 통합되어있다고 치자. 

     대리인이 10만, 매수인이 500만, 이해관계인 500만 이면, 대리인 10만 이것만 조회하려고 하는데

     총 1천 10만 테이블을 조회해야하니.. 얼마나 불필요한가.. 

 

 

 3-3. 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성

   그냥 테이블 하나에 쓰자 라는 주장... 2번 슈퍼+서브 로 통합하기 전에 그냥 한테이블 안에 있는것같다.

 

 4. 슈퍼/서브 타입 데이터모델의 변환타입 비교

 

 

 

 

 

❏  인덱스 특성을 고려한 PK/FK 데이터베이스 성능향상

 

 1. PK/FK 칼럼 순서와 성능개요

  - 데이터베이스에서는 균형잡힌 트리구조의 B*Tree 구조를 이용한다. 실전 프로젝트에서는 아주 중요한 내용이

      PK 순서이다. 앞쪽에 위치한 속성의 값이 " 비교자 " 로 있을 떄 효율이 가장 좋다.

      앞쪽에 위치한 속성 값이 = , < , > , BETWEEN 이 들어와야 인덱스를 쓸 수 있다.

 

 2. PK칼럼의 순서를 조정하지 않으면 성능이 저하된다

 

 

 

비교하는 범위가 매우 넓어져서 .. 전체를 읽어야 원하는 데이터를 찾을 수 있다.. 

이처럼 I/O가 많이 발생되서 그냥 전체를 읽어버리자.. 하고 처리를 한다. 

'PK 의 순서'도 생각 안하고 그냥 정의하면 안될 것 같다.

 

 3. PK 순서를 잘못 지정하여 성능이 저하된 경우 (간단한 오류)

 

 

입시마스터 I01 인덱스가 수험번호+년도+학기 중 수험번호에 대한 값이 where 절에 안들어와서

FULL SCAN이 발생. (사진 I-2-33 중 IE 표기법은 잘못 나온것. 33,34 둘다 Barker 로 볼 것)

 

그런데, PK 순서 하나만 바꿨을 뿐인데(수험번호,년도,학기 를 년도,학기,수험번호로) 

인덱스 스캔을 하게되서 성능이 향상되었다.

 

(딱봐도 간단한 오류여서 간단한 오류라고 했나..?)

 

 4. PK 순서를 잘못 지정하여 성능이 저하된 경우 - 복잡한 오류

 

언뜻 보면 인덱스 생성도 잘 됬고, 문제 없는것 같은데.. 문제는 없다. 그러나 효율이 ..!!?

 

 

전에 거래일자 가 ( BETWEEN 으로 ) 인덱스의 앞에 위치하기 때문에 범위가 넓고. 사무소코드 를 앞에두면 ( = 으로 )

범위가 좁아서 성능이 향상된다. 

 

오..

 

 

 

 

❏  물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 성능 저하

  

 

 

FK 인덱스를 사용합시다.   

물리적인 테이블에 FK 제약이 있으면 반드시 FK 인덱스를 생성하고,

FK 제약이 안걸려있어도 생성하는게 좋다. 그냥 FK 인덱스 쓰는게 무조건 좋네. 당연히 활용 안한다 싶으면 지우고.