Notice
Recent Posts
Recent Comments
Link
«   2025/08   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Archives
Today
Total
관리 메뉴

Ga0's

SQLD_데이터베이스 구조와 성능 본문

Study IT/SQLD

SQLD_데이터베이스 구조와 성능

Ga0Kwon 2023. 5. 3. 00:18

데이터베이스 구조와 성능

슈퍼/서브 타입 데이터 모델

 

1. 개요

  ▪ Extended ER 모델(= 슈퍼/서브타입 데이터 모델)은 최근 데이터 모델링에서 자주 쓰이는 모델링 방법으로 업무를 구성하는 데이터를 공통/차이점 특징을 고려하여 효과적으로 표현이 가능하다.

  ▪ 공통 부분은 슈퍼 타입으로 모델링하고, 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성은 서브타입으로 모델링한다. (서브엔터티로 구분하고, 정확하게 표현이 가능하다. 물리적인 데이터 모델로 변환할 때 선택의 폭을 넓힐 수 있는 장점이 있다.)

  ▪ 논리적인 데이터 모델에서 이용하는 형태로, 주로 분석단계에서 많이 쓰인다.

  ▪ 물리적 데이터 모델로 설계시 문제점이 발생하는데 이는 변환하는 방법의 노하우가 없어 1:1 or All in one(하나의 테이블로 구성)하는 현상이 나타나게 된다.

  ▪ 다시말하면 물리적 데이터 모델로 설계시(슈퍼/서브타입을 기준없이 변환시키려고 할때) 성능 저하의 위험이 존재한다.

 

2. 변환

   1) 성능 저하의 원인 3가지

        ▫ 트랜잭션은 항상 일괄로 처리하여 테이블이 개별로 유지되어 Union(두 테이블을 더하고 중복값을 제거) 연산에 의해 성능이 저하

        ▫ 트랜잭션은 서브 타입 개별로 처리하여 테이블이 하나로 통합되어 불필요한 많은 데이터가 존재하게 되면서 성능이 저하

        ▫ 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하여 테이블은 개별로 유지되거나 하나의 테이블로 집약되어 있어 성능이 저하

 

   2) 슈퍼/서브 타입 변환 기준

        ▫ 데이터 양과 해당 테이블에 발생되는 트랜잭스의 유형에 따라 결정

        ▫ 데이터가 소량이면, 데이터 처리 유연성을 고려하여 가급적으로 1:1 관계를 유지

        ▫ 데이터가 대량이거나 업무적인 특징이 성능에 민감한 경우 개별테이블, 슈퍼+서브타입 테이블, 하나의 테이블중 어떻게 발생되는 지에 따라 3가지 변환방법을 참조하여 변환

출처 : https://chae-developer.tistory.com/61

3. 변환 기술

  ▪ 개별로 발생되는 트랜잭선은 개별 테이블로 구성

  ▪ 슈퍼+서브타입에 대해 발생되는 트랜잭션은 슈퍼타입+서브타입 테이블로 구성

  ▪ 전체를 하나로 묶어 발생되는 트랜잭션 : 하나의 테이블로 구성

 

쪼개질수록 확장성이 증가하고, 조인성능은 감소하며, I/O 성능은 증가하고, 관리용이성은 떨어진다.

 

4. PK/FK 컬럼 순서와 성능 개요

  ▪ 인덱스의 중요성 : 데이터 조작시 가장 효과적으로 처리될 수 있도록 (PK/FK 칼럼 순서와 성능 개요 데이터를 조회할 때 가장 효과적으로 처리)접근 경로 제공 오브젝트

→ 데이터 베이스 테이블에서 군형 잡힌 트리구조를 많이 사용하는데, 이에 있어 PK/FK 설계는 데이터를 접근할 때 경로를 제공하는 성능 측면에서 중요한 의미이다.

  ▪ PK/FK 설계의 중요성 : 데이터 접근할 때 접근 경로 제공, 설계 단계 마지막에 컬럼 순서 조정

  ▪ PK 순서의 중요성 : 물리적인 모델링 단계에서 모델링 단계에서 스스로 생성 PK 이외에 상속 PK 순서도 주의

  ▪ FK 순서의 중요성 : 조인의 경로 제공 역할 수행. 조회 조건을 고려하여 반드시 인덱스 생성

 

5. PK 순서를 조정하지 않으면 성능 저하가 되는 이유

  ▪ 조회 조건에 따라 인덱스를 처리하는 범위가 달라짐(인덱스 = 고유값)

  ▪ PK의 순서를 인덱스 특징에 맞게 생성하지 않고 자동으로 생성하게 되면 테이블에 접근하는 트랜잭션이 비효율적인 인덱스에 의하여 인덱스를 넓은 범위로 스캔하거나 풀 스캔 유발

 

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

  ▪  물리적으로 두 테이블 사이에 FK 참조 무결성 관계를 걸어 상속받은 FK에 대해 인덱스를 생성

  ▪  FK 제약이 걸리지 않았을 경우 FK 인덱스를 생성하는 것은 기본 정책을 하되 트랜잭션에서 거의사용하지 않을 때만 fK를 지운다.

  ▪  FK 제약을 걸었을 때는 반드시 FK 인덱스를 생성

10

'Study IT > SQLD' 카테고리의 다른 글

데이터 모델링의 이해  (2) 2024.01.02
SQLD_분산 데이터베이스와 성능  (2) 2023.05.03
SQLD_대량 데이터에 따른 성능  (3) 2023.04.30
SQLD_반정규화  (0) 2023.04.28
SQLD_정규화  (1) 2023.04.28