대량 데이터에 따른 성능 관리

성능 저하가 일어나는 경우)

 

1. 한 테이블에 데이터가 대량으로 집중되어 있는 경우 

- 한 테이블에 대량의 데이터가 있을 때 인덱스를 사용해도 성능이 개선되지 않을 경우

 

해결방법) 

- 사용자에겐 하나의 테이블로 보이지만 물리적으로 여러 개의 테이블 스페이스에 쪼개어 저장되는 파티셔닝을 적용 

 

파티션 종류)

1. Range Partition 

ex) 요금 테이블에서 많은 데이터가 존재함으로 인해 성능이 저하되는 경우 

- 요금의 특성상 월단위로 데이터 처리를 하는 경우가 많으므로 월별로 쪼개서 12개의 파티션 테이블을 만듦 

 

- 하나의 테이블에서 관리하면 12억건의 데이터를 관리하는데 Range Partition을 적용하면 월별로 파티션이 쪼개지므로 평균 1억 건의 관리함으로써 성능이 개선됨 

 

- 데이터 보관주기에 따라 테이블에 데이터를 쉽게 삭제할 수 있음(월별로 나눠진 파티션 테이블 중에서 필요 없는 파티션만 지우면 됨) 

 

2. List Partition

 

 

 

2. 하나의 테이블에 여러 개의 칼럼이 존재하여 디스크에 많은 블록을 점유하는 경우 

- 컬럼(속성)이 많아지게 되면 물리적인 디스크의 여러 블록에 데이터가 저장되는데 데이터를 처리할 때 여러 블록에서 데이터를 I/O해야 하는 경우 성능이 저하될 수 있다. 

 

- 로우체이닝(Row Chanining) : 로우(행) 길이가 너무 길어서 블록 하나에 데이터가 모두 저장되지 않고 두 개 이상의 블록에 걸쳐 하나의 로우가 저장되는 형태 

 

- 로우 마이그레이션(Row Migration) : 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에다 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장하는 방식 

 

--> 로우체이닝과 로우 마이그레이션이 발생하여 많은 블록에 데이터가 저장되면 데이터베이스 메모리에서 디스크와 I/O(입력/출력)이 발생할 때 불필요한 I/O 많이 발생하여 성능이 저하됨 

 

해결방법)

- 테이블을 쪼개어서 컬럼들을 분리시킨다. 

 

 

조회 조건에 따른 인덱스를 적절하게 이용하면 해당 테이블에 데이터가 많아도 원하는 데이터만 인덱스를 통해서 접근을 하기 때문에 I/O량이 크게 증가하지 않을 수도 있다고 생각할 수 있지만, 대량의 데이터가 하나의 테이블에 존재하게 되면 인덱스를 생성할 때 인덱스의 크기가 커지게 됨으로써 인덱스를 찾아가는 단계가 오래 걸리게 되어서 조회 시 성능에도 영향을 미칠 수 있다. 데이터를 입력/수정/삭제하는 경우에는 조회 시보다 성능이 더 저하됨