데이터베이스 질문과 답변
안녕하세요.
다름이 아니라 DB Table 들을 관리하면서 의문점이 든게 있는데요.
Normal Table 하고 Partition Table 이 있는데..
Partition Table 이 Data 를 날짜별로 관리할 때 Drop Partition 하면 속도도 빠르고 Tablespace 관리도 되고.. 또 Select 할 때도 Partition Range 하면 Access 하는 양도 적고.. 여러모로 이득이 있는거 같은데..
그렇다면 모든 Table을 Partition Table 로 만드는게 더 좋지 않을까요?
만약 모든 Table 들을 Date Column 을 Partition Key 로 잡을 수 있고, 관리하는데 어려움만 없다면
기존에 있는 모든 Table 들을 Partition Table 로 만들어버리고 싶은데..
혹시 이러면 문제가 생길까요?
감사합니다~~~
데이터량에 따라 결정하는 것입니다.
대용량 테이블의 경우 파티션이 많은 장점을 가지지만
소량의 테이블에 있어 파티션의 장점은 전혀 드러나지 않습니다. 단점만 남죠.
답변 감사드립니다.
단점을 몇 가지 남겨 봅니다.
- 구매/유지비용: Partition Table 기능을 사용하려면, Enterprise Edition 이라고 불리는 가장 비싼 DB 모듈을 구매 후에, Partitioning 이라는 추가 옵션도 구매해야 해서 돈이 많이 듭니다. 몇배 이상 비쌉니다. Oracle 제품은 매년 유지보수 비용도 Oracle 사에 지불해야 하는데, 비용이 초기 구매가의 일정 비율이라 3년만 사용해도 엄청난 금액이 됩니다.
- 관리공수 : 일부 Partition 은 Data 가 들어오면 Partiton 이 자동으로 생성되게 할 수도 있지만, 아직 bug 도 fix 가 덜 됬고 이름도 원하는 형태로 지정할 수 없습니다. 그래서 대부분 (통상 날자 기준 Partition 의 경우는) 2-3년 치를 일괄 생성하고, 이후에 주기적으로 생성해줘야 합니다. 기타.. 관리를 위해 신경써야 할 Point 가 많습니다.
- 성능: 일단 작은? Table 은 Partiton 으로 생성하면 더 느려집니다. 또,, (DB에서 통계정보를 자동갱신 하는 스케줄이 있고, 통계가 달라지면 SQL 성능도 많이 차이가 나게 되는데. 자동갱신 기본 설정값은 통계가 없거나, Table 단위 10% 이상 Data 변경이 이루어진 경우 등을 인지에 평일 22시 부터 갱신 입니다.) 그래서 특정 Partition Table 에만 data 가 들어오면 통계 갱신도 안 되고 (그 Partition 관련 왜곡 통계가 남고) 운이 안 좋아 그 Partition Table 을 조회하게 되면 2-3초 걸리던 SQL 이 30분 이상 걸릴수도 있습니다. => 그래서 이런 작업 후에는 해당 Partiton 에 대한 통계 관리를 따로 합니다.
-
답변 감사드립니다. 생각지도 못한 부분이 있네요 ㅎㅎ
윗분이 적어주신거에 추가로 partition key가 안들어간 조회 쿼리를 index range scan으로 푼다...라고 하는순간 관리가 무지막지하게 귀찮아 집니다.
- local index로 만들시 : where 조건에 partiton key가 없으면 full scan이나 그에 준하는 최악의 플랜이 나올수 있음
- global index로 만들시 : truncate/drop partition 날리는 순간 index가 unusable. rebuild 하기 전에는 해당 index로 인해 DML 에러 발생.
무조건 바꾸기 보다는 어떤 쿼리를 쓸지, 데이터 분포도는 어떤지 고려해서 하는게 좋습니다.
답변 감사드립니다. local index 를 많이 사용하는데.. 아직까지는 큰 문제가 없어서 말씀하신 부분은 생각해보질 못했네요. 공부를 더 해야겠습니다. ㅎ
안녕하세요
파티션 사용시 고려 사항
1. 성능
1). SQL
- 서비스 SQL에서 해당 테이블의 월 or 년 엑스 패턴이 많다면? ( O )
가). 집계 테이블 고려 ? ( O )
- 집계 테이블 부분적 고려 가능 ( 실시간 데이터 확인 니즈 발생 )
A. 집계 테이블 + 실테이블 ( UNION ALL )
- 집계 테이블 고려 가능 : 집계 테이블 및 논 파티션 테이블
나). 집계 테이블 고려 ? ( X )
- 월 or 년 파티션 테이블 전환 or 생성
- 아웃터 테이블 풀린다면? ( 아래 참조 )
- 서비스 SQL에서 해당 테이블의 월 or 년 엑스스 패턴이 적다면?
가). 논파티션
- 아웃터 테이블 풀린다면?
가). 일 집계로 사용하지만 월 파티션 고려 : 파티션 찾는 블럭 부하 감소
나). 로우는 글로벌 인덱스로 생성
- 드럽 OR 트런케이트시 인덱스 업데이트 옵션 으로 테이블락 해소 ( UNUSABLE X, REBUILD X )
2) . EVENT
- 과도한 인서트로 인한 인덱스 컨텐션 이벤트가 다량으로 발새응로 액티브 세션이 춤을 준다? ( O )
가). 결합 파티션 고려
- 레인지 해쉬 파티션
나). 발생 컬럼 분석 - 오른쪽 증가 인덱스 ( 날짜 or PK )
- 날짜 컬럼 싱글 인덱스에 후행 컬럼으로 데이터 구분 컬럼 추가로 다른 블럭을 사용하겠끔 유도 : 인덱스 스위치
3). PARALLEL
- 성능 향상 도모 가능
2. 관리
1). DLM ( 데이터 라이브 사이클 관리 )
- 데이터 보관주기 1년
- 엑세스 페텬 확인 : 월 or 로우
- 아웃터 테이블로 풀린다면?
가). 일 집계로 사용하지만 월 파티션 고려 : 파티션 찾는 블럭 부하 감소
나). 로우는 글로벌 인덱스로 생성
- 드럽 OR 트런케이트시 인덱스 업데이트 옵션 으로 테이블락 해소 ( UNUSABLE X, REBUILD X )
답변 감사드립니다. 저희가 하루발생 Row 가 몇억건이다보니 대부분 일로 Partition 을 해서 관리하고 있습니다.
DLM 하고 Index update 옵션은 처음 들어봤네요. 공부를 더 해봐야겠습니다.
) 버튼을 클릭하여 작성 하시면 됩니다.