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

 

1️⃣ 대량 데이터에 따른 성능 문제, 성능 향상법

대량 데이터 집약 → 설계가 잘 된 데이터 모델이라도 성능 저하 불가피 → 테이블 단위 분할을 통한 문제 해결

 

✅ 성능 저하

DB의 블록에 많은 데이터가 저장됨 → 데이터 조회 과정에서 블록 입/출력 횟수 증가

• 로우 체이닝(Row Chaining) : 행 데이터가 너무 길어 2개 이상의 블록에 걸쳐 하나의 행이 저장된 형태
• 로우 마이그레이션(Row Migration) : 데이터 블록에서 발생한 수정이 다른 블록의 빈 공간에 잘못 저장 처리된 방식

 

✅ 분할 방식

• 수평 분할 : 행(로우)  ➡️  단위로 요소 분할
• 수직 분할 : 열(컬럼)⬇️ 단위로 요소 분할

 

✅ 분할 절차

1. DB 모델링
2. DB 테이블의 용량 산정
3. 데이터 처리 과정에서 트랜잭션 처리 패턴 분석
4. 데이터 처리과정이 칼럼, 로우 중 어디에 집중되는지 분석 후 파티셔닝

 

✅ 분할 기준

• 범위 분할 : 특정 기간을 중심으로 분할 ex. 보관 주기에 따른 테이블 분할
• 목록 분할 : 값 목록에 파티션을 할당 ex. country 컬럼 속 수많은 나라 → country_asia 등 대륙 별로 나누기
• 해시 분할 : 해시 함수의 값에 따른 분할 ex. 주문 번호와 같은 unique 컬럼 기준으로 나누기
  • 장점
    • 해싱 알고리즘에 의한 분리 → 기존 1개 테이블에만 데이터 입력하는 것보다 부하가 줄어듦
    • 범위 분할의 단점(특정 파티션에 데이터가 집중될 가능성)을 보완
    • 데이터 처리가 많아지는 경우, 경합을 방지
  • 단점
    • 데이터 보관 주기에 따라 쉽게 삭제하는 기능 제공 어려움
    • 설계자 및 데이터 입력자는 특정 데이터가 어떤 파티션에 저장되는지 예측 어려움
• 합성 분할 : 위 세 가지 분할 방식을 섞는 방식 

 

 

 

2️⃣ 슈퍼타입 / 서브타입 모델 

데이터 특징을 공통점, 차이점으로 나누어 표현하여 직관적 모델링이 가능한, 잘 쓰이는 데이터 모델링 기법

 

✅ 모델 변환 방법

방법		설명
슈퍼 타입	Single Type All in One Type	슈퍼/서브 타입 모델 → 하나의(Single) 테이블로 변환
서브 타입	Plus Type Super+Sub Type	슈퍼타입, 서브타입 테이블로 변환 각 타입에는 변환 전 슈퍼 엔터티에 있던 공통 컬럼을 가짐
개별 타입	OneToOne Type 1:1 type	슈퍼/서브 타입 모델 → 슈퍼 타입, 서브 타입 개별 테이블로 변환 각 테이블 모두 생성

 

✅ 모델 변환 타입 비교

구분	슈퍼 타입	서브 타입	개별 타입
특징	하나의 테이블	각각의 서브 타입 테이블	슈퍼 타입 테이블, 서브 타입 테이블
확장성	🔴	🟡	🟢
조인 성능	🟢 🟢	🔴	🔴
I/O 성능	🔴	🟢	🟢
관리 용이성	🟢	🟡	🟡

* 🟢🟢우수함, 🟢좋음, 🟡보통, 🔴나쁨

 

✅ 모델 변환의 중요성

트랙잭션은 항상 일괄적으로 처리

트랜잭션은 항상 서브타입을 개별로 처리

트랙잭션은 항상 슈퍼타입과 서브타입을 공통으로 처리

 

✅ PK 순서와 성능

• 테이블에 기본키(PK)는 항상 존재, PK는 단일PK 혹은 복합PK가 될 수 있음
• 복합PK의 경우, 데이터 성능 향상을 위해 테이블에 발생되는 트랜잭션 조회 패턴에 따라 컬럼 순서 조정 필요

 

✅ FK와 테이블 인덱스 구성 간 관계

• 논리 데이터 모델 상 관계(Relationship)에 의한 외래키(FK) 제약이 걸린 경우, 물리 DB가 어떻게 설계되었는지에 따라 실제 적용 여부가 나뉨
• FK 생성 여부와 관계없이, 논리/물리 FK 제약 조건은 FK 컬럼에 대해 인덱스를 생성하는 것이 성능 상 우위를 가짐

 

 

 

3️⃣ 분산 데이터베이스와 성능

여러 곳에 분산되어 있는 데이터베이스 시스템을 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스

 

✅ 특징

• 분산된 DB를 하나의 가상 시스템으로 사용
• 논리적으로 동일한 시스템이지만, 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임
• 물리적으로 분산되어 있지만, 논리적으로 하나의 DB를 다루는 것처럼 사용자를 통합

 

✅ 투명성

종류	설명
분할 투명성	논리적 관계 1개 → 여러 단편으로 분할 → 각 사본이 여러 사이트에 저장됨 사용자는 분할 저장된 게 아니라, 한 곳에 모두 위치한 것처럼 느껴야 함
위치 투명성	위치 정보 - System Catalog에 유지 사용자는 데이터의 위치를 신경 쓸 필요 X, 데이터 저장소를 명시할 필요도 X
지역 사상 투명성	지역 DBMS와 물리적 DB 사이의 mapping 보장 각 지역 시스템 이름과 무관한 이름 사용 가능 데이터가어느 지역에 있는지 알 필요 X
중복 투명성	DB 객체가 여러 사이트에 중복되어 있는지 알 필요 X
장애 투명성	구성 요소에서 발생하는, 장애에 무관한 트랜잭션의 원자성 유지
병행 투명성	다수 트랜잭션 동시 수행 시 결과의 일관성 유지 구현: 1단계 Timestamp, 2단계 Locking

 

✅ 주의

만능이 아니므로, 모든 환경에서 적용은 X, 업무 구성에 따른 아키텍처 고려 후 적용 必

 

✅ 장단점

장점	단점
지역 자치성, 점증적 시스템 용량 확장	소프트웨어 개발 비용 증가
신뢰성 & 가용성	오류의 잠재성 증대
효용성 & 융통성	처리 비용의 증대
빠른 응답 속도 & 통신 비용 절감	설계 및 관리의 복잡성과 비용
데이터의 가용성 & 신뢰도 증가	불규칙한 응답 속도
시스템 규모의 적절한 조절	통제의 어려움
각 지역 사용자의 요구 수용 증대	데이터 무결성에 대한 위협 (전처리 필요)

 

✅ 적용 기법

• 테이블 위치(Location) 분산
• 테이블 분할(Fragmentation) 분산
  • 수평 분할 : 행(row)으로 분리
  • 수직 분할 : 열(column)로 분리
• 테이블 복제(Replication) 분산
  • 부분(Segment)복제
  • 광역(Broadcast)복제
• 테이블 요약(Summarization) 분산
  • 분석(Rollup)요약 : 상품A의 모든 판매 실적을, 모든 분산 DB가 가지고 있지만, 디테일한 실적은 모두 다르며, 통합하는 DB가 전체 산출
  • 통합(Consolidation)요약 : 각 상품DB마다 다른 상품에 대한 데이터를 가지고, 이를 통합 DB가 모아서 전체 산출