[SQLD] 1과목 요약 정리: 1-2 데이터 모델과 성능
Note/Certificate

[SQLD] 1과목 요약 정리: 1-2 데이터 모델과 성능

728x90
반응형

 

성능 데이터 모델링

  • 데이터베이스 성능향상을 목적으로 설계 단계의 데이터 모델링 때부터 정규화, 반정규화, 테이블 통합, 테이블 분할, 조인구조, PK, FK 등 반영
  • 초기 단계에 고려할수록 재업무 비용 최소화
  • 프로세스
    1. 데이터 모델링을 할 때 정규화를 정확히 수행
    1. 데이터베이스 용량산정 수행
    1. 데이터베이스에 발생되는 트랜잭션의 유형 파악
    1. 용량과 트랜잭션의 유형에 따라 반정규화 수행
    1. 이력 모델의 조정, PK/FK 조정, 슈퍼/서브타입 조정
    1. 성능 관점에서 데이터 모델 검증

정규화

  • 데이터를 결정하는 결정자에 의해 함수적 종속을 가진 일반속성을 의존자로 하여 입력/수정/삭제 이상을 제거
  • 한 테이블에 인덱스가 많아지만 조회 성능 향상, 입력/수정/삭제 성능 저하
  • 함수적 종속성: 데이터들이 어떤 기준값에 의해 종속되는 현상
    • 기준값: 결정자, 종속값: 종속자

반정규화(=역정규화)

💡
반정규화만이 조회 성능을 향상시키는 것은 아님 (정규화를 해야 향상되는 경우 존재)
입력/수정/삭제 성능 저하
  • 정규화된 엔티티, 속성, 관계에 대해 시스템의 성능향상과 개발, 운영의 단순화를 위해 중복, 통합, 분리 등을 수행하는 기법
  • 데이터 무결성이 깨질 수 있는 위험 존재.
    but, 데이터 조회 시 디크스 I/O량이 많아서 성능이 저하되거나 경로가 너무 멀어 조인으로 인한 성능 저하가 예상될 경우 수행
  • 정규화의 함수적 종속관계는 위반하지 않지만 데이터 중복성을 증가시켜 조회 성능 향상
  • 적용 방법
    1. 반정규화 대상 조사: 데이터 양 조사, 성능 저하 예측
      • 범위 처리 빈도수 조사
      • 대량의 범위 처리 조사
      • 통계성 프로세스 조사
      • 테이블 조인 개수 조사
    1. 다른 방법 유도 검토: 데이터 무결성 깨뜨릴 위험 제어
      • 많은 조인 → 뷰 테이블 이용 검토
      • 대량의 데이터 처리, 부분처리 → 클러스터링(저장방식 다르게) 적용, 인덱스 조정
      • 대량의 데이터 → 파티셔닝 기법(부분적인 테이블로 분리)
      • 응용 애플리케이션 로직 구사
    1. 반정규화 적용: 테이블, 속성, 관계 고려
  • 테이블 반정규화
    1. 테이블 병합: 1:1, 1:M, 슈퍼/서브타입 병합
    1. 테이블 분할: 수직분할, 수평분할
    1. 테이블 추가: 중복/통계/이력/부분 테이블 추가
  • 칼럼 반정규화
    1. 중복칼럼 추가: 조인 감소
    1. 파생칼럼 추가: 미리 계산한 값
    1. 이력 테이블 칼럼 추가
    1. PK에 의한 칼럼 추가: 단일 속성의 PK에서 특정 값을 별도로 조회하는 경우, 일반 속성으로 포함
    1. 응용시스템 오작동을 위한 칼럼 추가: 이전 데이터 임시 중복 저장
  • 관계 반정규화 (무결성 깨질 위험 없음)
    1. 중복관계 추가

대량 데이터

  • 대량의 데이터 존재 = 인덱스의 tree 구조 증가 = 디스크 I/O 다량 유발
    ⇒ 성능 저하 (인덱스 크기 커짐)
  • 로우체이닝 현상: 로우 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고 두 개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태
  • 로우 마이그레이션: 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장하는 방식
  • 해결법
    • 테이블 분할
      1. 수평분할
      1. 수직분할
    • 파티셔닝
      1. 범위: 대상 테이블이 날짜 또는 숫자 값으로 분리 가능, 영역별로 트랜잭션 분리가 가능한 경우, 데이터 보관 주기에 따른 관리
      1. 특정값 지정(list): PK가 지점, 사업장, 핵심적 코드값인 경우, 특정 값에 따라 분리 저장
      1. 해시: 해시 알고리즘 적용, 보관주기x
      1. 범위와 해시 복합(composite)

데이터베이스 구조와 성능

  • 슈퍼타입/서브타입 데이터 모델 = Extended ER모델
    • 공통 부분을 슈퍼타입으로 모델링, 공통으로부터 상속받아 다른 엔티티와 차이가 있는 속성은 별도의 서브타입으로 구분
    • 논리적 데이터 모델 / 분석 단계 ⇒ 물리적 모델로 변환
    • 변환 시 성능 저하
      1. 트랜잭션은 항상 일괄로 처리, 테이블은 개별로 유지 → union연산에 의해 성능 저하
      1. 트랜잭션은 항상 서브타입 개별로 처리, 테이블은 하나로 통합 → 많은 데이터 집약돼 성능 저하
      1. 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리, 테이블은 개별로 유지되거나 하나의 테이블로 집약 → 성능 저하
    • 변환 기술
      1. OneToOne Type: 개별로 발생되는 트랜잭션에 대해 개별 테이블로 구성 (1:1)
      1. Plus Type: 슈퍼+서브타입에 대해 발생되는 트랜잭션에 대해 슈퍼+서브타입 테이블로 구성 (하나로 묶어 별도의 테이블로 구성)
      1. Single Type: 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성
  • 인덱스 특성 고려
    • PK/FK 칼럼 순서 조정
      • 앞쪽에 위치한 속성의 값이 비교자로 있어야 좋은 인덱스 효율
        (가급적 ‘=‘ 또는 최소한 범위인 ‘BETWEEN’, ‘<>’)
      • FK에 대해 반드시 인덱스 생성
      💡
      칼럼 순서 → 성능저하 이유?
      인덱스의 정렬 구조에서 조건에 따라 인덱스 처리 범위가 달라짐(접근 방법 달라짐)
      성능 저하 → 인덱스 범위를 넓게 이용하거나 풀스캔 유발
    • B*Tree 구조: 균형잡힌 트리구조

분산 데이터베이스

  • 여러 곳으로 분산되어있는 데이터베이스를 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스
  • 논리적으로 동일한 시스템, 물리적으로 분산되어 있는 데이터
  • 투명성
    1. 분할 투명성(단편화): 하나의 논리적 릴레이션이 여러 단편으로 분할되어 각 단편의 사본이 여러 사이트에 저장
    1. 위치 투명성: 데이터의 저장 장소 명시 불필요
    1. 지역사상 투명성: 지역 DBMS와 물리적 DB 사이의 매핑 보장
    1. 중복 투명성: 객체가 여러 사이트에 중복되어 있는지 알 필요 없음
    1. 장애 투명성: 구성요소의 장애에 무관한 트랜잭션 원자성 유지
    1. 병행 투명성: 다수 트랜잭션 동시 수행 시 결과 일관성 유지
  • 장점
    • 지역 자치성, 점증적 시스템 용량 확장
    • 신뢰성, 가용성, 효용성, 융통성
    • 빠른 응답 속도, 통신 비용 절감, 시스템 규모의 적절한 조절, 각 지역 사용자의 요구 수용 증대
  • 단점
    • 개발 비용, 오류 잠재성, 처리 비용, 관리의 복잡성, 불규칙한 응답 속도, 통제 어려움, 데이터 무결성 위협
  • 적용 기법
    1. 테이블 위치 분산: 테이블 구조 변경 없음, 중복 없음, 위치만 다름 → 도식화된 위치별 데이터베이스 문서 필요
    1. 테이블 분할 분산: 각각의 테이블을 쪼개어 분산, 지사별로 별도로 존재, 데이터 중복 없음, 데이터 무결성 보장, 조인 필요
      • 수평분할(로우 단위)
      • 수직분할(컬럼 단위)
    1. 테이블 복제 분산: 동일한 테이블을 다른 지역이나 서버에 동시 생성, 지사간 중복 없음, 본사와 지사간 중복 발생, 실시간보다 배치 작업에 의해 수행
      • 부분복제(지사에서 이벤트 발생, 본사에서 이용)
      • 광역복제(본사에서 이벤트 발생, 지사에서 이용)
    1. 테이블 요약 분산: 데이터가 비슷하지만 서로 다른 유형으로 존재
      • 분석요약(동일한 내용의 데이터를 이용)
      • 통합요약(다른 내용의 데이터를 이용)
  • 적용 예시
    • 성능이 중요한 사이트
    • 공통코드, 기준정보, 마스터 데이터 등에 대해 분산환경 구성
    • 실시간 동기화 요구되지 않을 때 좋음
    • 특정 서버에 부하가 집중돼 부하를 분산할 때 좋음
    • 백업 사이트
728x90
반응형