정처기, 20230415

cptkuk91·2023년 4월 15일
0

EIP

목록 보기
11/20

DB 물리적 설계 단계에서 수행하는 사항

  • 저장 레코드 양식 설계
  • 레코드 집중 분석 및 설계
  • 접근 경로 설계

DB 물리적 설계 수행 시 결정 사항

  • Index 구조 (어떤 Index를 만들 것인지)
  • 성능 향상을 위한 개념 스키마의 변경 여부 검토
  • 빈번한 질의와 트랜잭션들의 수행 속도를 높이기 위한 고려

데이터 명명 규칙

  • 조직마다 다를 수 있어 설계전에 미리 파악해야 한다.
  • 설계 시 중복 구축을 방지하는데 도움을 준다.
  • 논리적 데이터 요소를 물리적 요소로 전환할 때 동일 명칭 부여 근거로 사용된다.

DB의 모든 데이터가 저장되는 테이블

  • 테이블은 Row, Col로 구성되어 있다.
  • 일반 테이블, 클러스트 인덱스 테이블, 파티셔닝 테이블이 있다.
  • Column은 데이터 타입과 길이로 정의된다.

Column이란?

  • 테이블을 구성하는 요소다.
  • 데이터 타입과 길이로 정의된다.
  • 데이터 타입과 길이가 달라도 비교할 수 있다. (DMBS 내부적으로 변환)
  • 참조 관계인 컬럼은 데이터 타입과 길이가 동일하다.

일반 테이블

  • 데이터 Row위치는 속성값에 상관없이 저장되는 순서에 따라 결정된다.

클러스트 인덱스 테이블

  • 기본키, 인덱스 순서에 따라 데이터가 저장된다.

임시 테이블

  • 절차적인 처리를 위해 임시로 사용하는 테이블이다.
  • 트랜잭션 종료 시 삭제된다.

외부 테이블

  • 외부 파일을 데이터 베이스 내의 테이블처럼 사용할 수 있다.

테이블 스페이스

  • 하나 또는 하나 이상의 테이블을 저장할 수 있다.
  • 테이블이 저장되는 논리적인 영역이다.
  • 하나 또는 하나 이상의 데이터 파일을 저장할 수 있다.
  • 투명성이 보장된다.

트랜잭션의 특성

  1. 원자성(Atomicity): 완전히 수행하든지, 하나도 수행하지 말든지 (하나라도 오류가 나면, 트랜잭션 전부 취소)
  2. 일관성(Consistency): 일관성 있는 DB 상태로 변환
  3. 격리성(Isolation): 트랜잭션 수행 중 다른 트랜잭션 연산이 낄 수 없다.
  4. 지속성(Durability): 트랜잭션 완료 결과는 DB에 영구히 기억된다.

CRUD 분석 순서

R → U → D → C 따라 한가지만 적는다.

CRUD 검토 사항

  • 테이블에 CRUD 모두 없으면 검토해야 한다.
  • 테이블 C 또는 R이 없는 경우 검토한다.
  • 프로세스에 CRUD 모두 없는 경우 검토

Index에 대한 설명

  • 물리적 구조와 밀접한 관계가 있다.
  • 삽입, 삭제가 수시로 일어나면 Index 개수를 최소화해야 한다.
  • Index를 통해 테이블(파일)레코드에 대한 엑세스를 빠르게 수행할 수 있다.

함수 기반 인덱스

  • 인덱스가 컬럼 값 자체가 아니라 컬럼에 특정 함수나 수식을 적용
  • 데이터가 아닌 함수라 부하가 발생할 수 있다.
  • B+ 트리인덱스, 비트맵 인덱스를 생성하여 사용한다.

뷰 테이블

  • DB 관리자가 사용자에게 허용된 자료만을 제한적으로 보여주기 위한 테이블
  • 뷰를 삭제하면 정의된 다른 뷰도 삭제된다.
  • 뷰는 물리적 테이블이 아니라 가상 테이블이다.

클러스터

  • 엑세스 효율 향상, 동일한 성격의 데이터를 동일한 데이터 블록에 물리적 저장
  • 조회 속도는 향상시키지만, 입력, 수정, 삭제에 대한 성능 저하
  • 분포도가 넓은 테이블 클러스트 사용 시 저장 공장 절약
  • 파티셔닝 테이블은 클러스트 사용이 불가능하다.

인덱스 파티션

  • Local Partitional Index: 테이블 파티션과 인덱스 파티션 1:1 대응
  • Global Partical Index: 테이블 파티션과 인덱스 파티션 독립적 구성 (인덱스가 독립된다는 건 데이터 관리가 어려워진다는 뜻이다.)
  • 결국 파티션은 테이블을 작은 논리적 단위로 나눈 것이고, 데이터 가용성이 향상된다.
  • 용량이 작은 테이블은 파티셔닝 수행 시 오히려 성능이 저하된다. 따라서 큰 테이블을 파티셔닝!

DB 용량 설계

  • 데이터 예상 건수, 로우 길이, 보존 기간, 증가율 등 기초 자료를 수집 분석해야 한다.
  • 데이터를 정확히 산정하면 확장성 및 가용성을 높일 수 있다.
  • 입출력 경합을 최소화하려면 테이블, 인덱스를 분리
  • (용어)익스텐드: 용량이 가득차 추가적 용량을 할당

DB 분산

  • 비용을 증가시킨다.
  • 분산 DB는 하나가 고장나도 작동한다. 하지만 DB가 분산된 만큼 오류(고장) 확률이 높다.
고장 확률이 높은 이유
1. 서버 문제: 서버가 많은 DB와 연결된 만큼 네트워크 문제가 발생할 가능성이 높아진다.
2. 일관성 유지 문제: 일부 서버에서 데이터 불일치가 발생할 경우 오류가 발생한다.
3. 병목 현상: 서버 간 작업 분배, 데이터 전송에 따른 병목 현상 발생은 오류로 이어짐.

분산 DB

  • 위치 투명성: 실제 위치 알 필요없이 논리적인 명칭으로 엑세스
  • 중복 투명성: 중복 개수, 사실을 알 필요가 없다. 중복에 관계없이 데이터 처리 가능
  • 병행 투명성: 다수의 트랜잭션이 실현(실행)되더라도 트랜잭션 결과는 영향을 받지 않습니다.
  • 장애 투명성: DBMS, 네트워크, 컴퓨터 장애가 있어도 트랜잭션 정확히 처리

DB 이중화

  • 동일 DB를 복제
  • 하나를 수정하면 다른 DB도 수정
  • 하나 문제 발생 시 다른 DB 사용
  • Eager 기법: 즉시 반영
  • Lazy 기법: 트랜잭션 발생 시 새로운 트랜잭션 생성 해 다른 DB에 전달
  • 활동-대기(Active, Standby)기법: 하나는 활성, 하나는 대기 (설정이 쉽다.)
  • 활동-활동 기법: 하나로 서비스하다가 고장나면 다른 DB가 즉시 작동 (설정이 복잡하다.)

DB 암호화

  • 공증키: 암호화, 복호화가 서로 다른 키를 사용
  • 개인키: 암호화, 복호화 한 개의 키 사용

profile
메일은 매일 확인하고 있습니다. 궁금하신 부분이나 틀린 부분에 대한 지적사항이 있으시다면 언제든 편하게 연락 부탁드려요 :)

0개의 댓글