2024 01 29
2024-01-29¶
파티셔닝 테이블¶
참고: https://coding-factory.tistory.com/840
- 개요
- 논리적으로는 하나의 테이블이지만, 물리적으로는 여러개의 파티션으로 나뉘어 데이터들이 각각에 세그먼트에 저장되는 테이블
- 파티션 테이블에는 Pruning 이라는 기능을 통해 특정 데이터 조회 시, 그 데이터가 속한 세그먼트만 빠르게 조회할 수 있음
- 논리적으로는 하나의 테이블이기에, 조회 쿼리문을 특별히 수정할 필요 X
- 그 와중에 데이터는 물리적으로 다른 세그먼트에 저장되어 관리 측면 굿
- 장점
- Select Query 퍼포먼스 향상 (Full Table Scan의 범위가 작아짐)
- 디스크 장애시 해당 파티션만 손상됨
- 개별 Partition 단위의 관리가 가능
- 개발되어 있는 기존 쿼리문 수정할 필요 X
- 조인 시 파티션간 병렬 처리 및 파티션 내의 병렬 처리 수행
- 데이터 액세스 범위를 줄여 성능 향상 + 테이블 파티션 단위로 디스크 I/O 분산해 부하 감소
- 단점
- 파티션 키 값 변경에 대한 별도 관리 필요
- 파티션에 기준을 컬럼의 일부로 잡는다면, 정상적인 파티셔닝이 안됨 -> 오버헤드 칼럼이 필요할 수도
- Insert 속도 느려짐
- Join 비용 증가
- When to Use
- 데이터 양이 많고, Insert가 지속적으로 일어나는 테이블
- ex. 로깅 테이블
- insert 많음
- 몇 달 지나면 보지도 않음
- 필요없어진 거 그냥 띡하고 버릴수 있음
- 파티션 키 컬럼(파티셔닝 키)
- Range Partition Table에서 물리적으로 테이블이 나뉘는 기준이 되는 컬럼으로 많이 지정
- 날짜 컬럼으로 많이 지정
- Range Partitioning 시, Load balancing은 파티션 키에 의존!!!
- 여러 파티션에 대한 조회는 한 테이블로 구성시보다 효율 떨어짐 => 기준 키를 잘 구성하자!
- PK 처럼 뭔 데이터인지 모르겠는 건 피해
- 데이터가 어디에 있는지 직관적으로 알 수 있어야해
- I/O 부하 잘 분산할 수 있도록 분포도 적당해야 해
- 여러 파티션에 대한 조회는 한 테이블로 구성시보다 효율 떨어짐 => 기준 키를 잘 구성하자!
- Range Partition Table에서 물리적으로 테이블이 나뉘는 기준이 되는 컬럼으로 많이 지정
- 파티션 테이블의 종류
- Range Partitioning
- 일/월/분기 등 특정 컬럼의 정렬값 기준 분할
- 관리 용이, 이력 데이터에 적합
- 범위이다 보니... 특정 파티션에 편중될 수도 있음
- Hash Partitioning
- 데이터 균등 분할 통해 성능 향상을 꾀할 때 효율적
- 파티션 키 + Hash Function => 뚝딱
- List Partitioning (안 와닿음)
- 순서에 맞지 않는 데이터의 그루핑 쉽게 할 수 있다네...
- 오로지 하나의 칼럼만으로 파티션 키 생성 가능하다네...
- Range Partitioning
Scala foldLeft (마음에 와닿게)¶
- 개요
- 왼쪽 항부터 마지막 항까지 계산되는 것
Scala Fold¶
- 개요
- Fold: 주어진 결합함수를 데이터 구조에 대해 재귀적으로 호출하여 결과값을 만들어내는 HOF
- FoldLeft
- Fold를 왼쪽 방향으로 적용하겠습니다.
- 마지막 요소를 제외한 요소들을 재귀적으로 처리한 결과와 마지막 요소를 결합
- Scala 내부에서는?
- 재귀함수적으로 처리할법도 한데, 그냥 성능을 위해 while문 때려버림