Today?
챌린지반 DB part.4
EDR 용어정리
엔티티
데이터베이스 모델링 시 기본 원칙
- 업무에서 필요로 하는 모든 데이터가 모델에 정의되어야 함
- 두 개의 엔티티가 비슷한 애트리뷰트로 구성되면 -> 하나의 엔티티로 통합
- 애트리뷰트는 누구나 알기 쉽게 작성
- 애트리뷰트의 이름은 짧게!
- 애트리뷰트가 여러 개의 값을 가지면 엔트리로 바꾸는 게 낫다.
- 엔티티, 애트리뷰트는 명사이고 관계는 동사
- Data Redundancy 이슈가 발생하지 않아야 함(정규화)
- Data Redundancy : 데이터 중복
모델링을 하기 위해 알아야 할 것 : 인덱스
- 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조
- 통으로 검색하는
풀스캔은 지양한다...
Index의 종류
하나의 데이터베이스 내에서 클러스터형 인덱스를 가질 수도 있고 비클러스터형 인덱스를 가질 수도 있다...? 상황에 따라서 사용하는 인덱스를 다르게 사용하는 거
1. Clustered Index
- 클러스터형 인덱스 : 정렬된 데이터 row들을 탐색 키 값으로 가짐
- 정렬이 되어 있다는 전제조건 -> 검색 매우 빠름, 삽입 수정 삭제 느림
- 인덱스를 여러 개 가질 수 있음...
2. Non-Clustered Index
- 비클러스터형 인덱스 : 정렬되지 않은 데이터 row들을 탐색 키 값으로 가짐
- 별도 페이지에서 인덱스 구성 -> 추가적인 용량 필요
- 삽입, 수정, 삭제가 빠름... 검색은 느림.
- 실제 데이터 테이블과 인덱스-포인터가 저장된 테이블이 따로 있다...
R 빈도 >>> CUD 빈도
WHERE 절에 사용하는 컬럼들은 인덱스 유력 후보
인덱스를 안 거는 게 나을 경우
- 레코드 수가 적은 테이블: 테이블에 데이터가 매우 적을 경우, 인덱스를 사용하는 것보다 전체 테이블을 스캔하는 것이 더 빠를 수 있다. 인덱스를 조회하고, 실제 데이터에 접근하기 위한 추가적인 디스크 I/O가 오히려 오버헤드가 될 수 있기 때문
- 낮은 카디널리티(Cardinality): 카디널리티가 낮다는 것은 테이블의 특정 컬럼에 중복된 값이 많다는 것을 의미함... 예를 들어, 성별 컬럼과 같이 몇 가지 값만을 가지는 경우가 여기에 해당한다(M/F) Selectivity(분포도)가 낮다고 함.
- 이런 경우, 인덱스는 효율적인 검색을 돕기보다는 검색 시간을 오히려 늘릴 수 있으며, 대부분의 레코드를 스캔해야 할 수도 있다.
- 데이터 변경 작업이 빈번한 테이블: 인덱스는 데이터베이스에서 데이터를 추가, 수정, 삭제할 때마다 업데이트되어야 한다. 따라서 데이터 변경 작업(INSERT, UPDATE, DELETE)이 매우 빈번하게 발생하는 테이블의 경우, 인덱스 유지 관리로 인한 성능 저하가 발생함...이는 특히, 대량의 데이터를 처리해야 하는 배치 작업에서 문제가 될 수 있다.
- SELECT 문의 빈도가 데이터 변경 작업보다 많아야 함
- 검색 결과가 많을 경우 : 검색 결과가 전체 데이터의 20%를 넘으면 사용X
- 인덱스가 너무너무 많다 : 사용하지 않는 인덱스는 지워줍시다.
인덱스를 설계할 땐 주의하자~!
다음 시간에 서비스... 슬랙 분석함
