오늘의 나보다 성장한 내일의 나를 위해…
대량 데이터 발생에 따른 테이블 분할
대량의 데이터가 하나의 테이블에 집약되어 있고 하나의 하드웨어 공간에 저장되어 있으면 성능 저하를 피하기 쉽지 않다. 처리 하는 일의 양이 한군데에 몰리는 현상 은 어떤 업무에 있어서 중요한 업무에 해당되는 데이터가 특정 테이블에 있는 경우에 발생이 되는데 이런 경우 트랜잭션이 분산 처리될 수 있도록 테이블 단위에서 분할의 방법을 적용할 필요가 있는 것이다.
하나의 테이블에 대량의 데이터가 존재하는 경우
인덱스의 Tree 구조가 너무 커져 호율성이 떨어져 데이터를 처리(입력, 수정, 삭제, 조회)할 때 디스크 I/O를 많이 유발하게 된다. 또한, 인덱스를 생성할 때 인덱스의 크기가 커지게 되고 그렇게 되면 인덱스를 찾아가는 단계가 깊어지게 되어 조회의 성능에도 영향을 미치게 된다. 인덱스의 크키가 커질 경우 조회의 성능에는 영향을 미치는 정도가 작지만 데이터를 입력 / 수정 / 삭제하는 트랜잭션의 경우 인덱스의 특성상 일량이 증가하여 성능저하를 유발할 수 있다.
하나의 테이블에 많은 수의 칼럼이 존재
이 경우 데이터가 디스크이 여러 블록에 존재하므로 인해 디스크에서 데이터를 읽는 I/O량이 많아지게 되어 성능이 저하되게 된다. 또한, 물리적인 디스크에 여러 블록에 데이터가 저장되게 된다. 따라서 데이터를 처리할 때 여러 블록에서 데이터를 I/O해야 하는 SQL 문장의 성능이 저하될 수 있는 특징을 가지게 된다.
로우체이닝(Row Chaining)
로우 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고 두 개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태이다.
로우마이그레이션(Row Migration)
데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장하는 방식이다.
로우 길이가 너무 긴 경우 로우 체이닝과 마이그레이션이 발생하게된다. 많은 블록에 데이터가 저장되면, 데이터베이스 메모리에서 디스크와 I/O(입력/ 출력)가 발생할 때 불필요하게 I/O가 많이 발생해 성능이 저하된다.
한 테이블에 많은 수의 칼럼을 가지고 있는 경우
도서정보라고 하는 테이블에 칼럼수가 아주 많은 경우를 생각해보자. 이 때 화면을 몇 번 스크롤 하면서 보아야하고 이렇게 많은 컬럼을 가지고 있는 테이블에 대해서는 트랜잭션이 발생할 때 어떤 칼럼에 대해 집중적으로 발생하는지 분석하여 테이블을 쪼개어주면 디스크 I/O가 감소하게 되어 성능이 개선되게 된다.
도서정보 테이블에서는 전자출판유형에 대한 트랜잭션이 독립적으로 발생이 되는 경우가 많고 대체제품에 대한 유형의 트랜잭션이 독립적으로 발생되는 경우가 많이 있어 1:1 관계로 분리한다. 분리된 테이블은 디스크에 적어진 칼럼이 저장이 되므로 로우마이그레이션과 로우체이닝이 많이 줄어들 수 있다. 따라서 성능이 개선될 수 있다.
대량 데이터 저장 및 처리로 인한 성능
테이블에 많은 양의 데이터가 예상될 경우 파티셔닝을 적용하거나 PK에 의해 테이블을 분할하는 방법을 적용할 수 있다. Oracle의 경우 크게 List Partition(특정 값 지정), Range Partition(범위), Hash Partition(해쉬적용), Composite Partition(범위와 해쉬가 복합)**등이 가능하다.
데이터가 대량으로 많이 있을 때 논리적으로는 하나의 테이블로 보이지만 물리적으로는 여러 개의 테이블 스페이지에 쏘개어 저장될 수 있는 구조의 파티셔닝을 사용하면 성능을 개선할 수 있다.
Range Partition 적용
요금테이블에 PK가 요금일자+요금번호로 구성되어 있고 데이터 건수가 1억2천만건인 대용량 테이블의 경우이다. 하나의 테이블로는 너무 많은 데이터가 존재하므로 인해 성능이 느린 경우에 해당된다. 이때 요금 특성상 월단위로 데이터를 처리하는 경우가 많으므로 PK인 요금일자의 년+월을 이용하여 12개의 파티션 테이블(요금_0401~요금_0412)을 만든 결과이다.
가장 많이 사용되는 파티셔닝 기능이기도 하다. 대상 테이블이 날짜 또는 숫자값으로 분리가 가능하고 각 영역별로 트랜잭션이 분리된다면 Range Parition을 적용한다. 또한, 이 파티셔닝은 데이터 보관주기에 따라 테이블에 데이터를 쉽게 지우는 것이 가능하므로 (파티션 테이블 드랍 가능) 데이터 보관 주기에 따른 테이블 관리가 용이하다는 장점을 가진다.
List Partition 적용
지점, 사업소, 사업장, 핵심적인 코드값 등으로 PK가 구성되어 있고, 대량의 데이터가 있는 테이블이라면 값 각각에 의해 파티셔닝이 되는 List Partition을 적용할 수 있다.
아래 그림은 사업소코드별로 List Partition을 적용한 사례이다. 이는 대용량 데이터를 특정값에 따라 분리하여 저장할 수 있으나 Range Partiton과 같이 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.
Hash Partition 적용
기타 Hash Partition은 지정된 Hash 조건에 따라 해슁 알고리즘이 적용되어 테이블이 분리되며 설계자는 테이블에 데이터가 정확하게 어떻게 들어갔는지 알 수 없다. 이 기능 역시 데이터 보관 주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.
결론
칼럼 수가 많은 경우 트랜잭션 특성에 따라 테이블을 1:1 형태로 분리할 수 있는지 검증하면 된다.
그러나 칼럼의 수가 적지만 데이터 용량이 많아 성능 저하가 예상이 되는 경우 테이블에 대해 파티셔닝 전략을 도모하도록 한다. 이때 임의로 파티셔닝할 것인지 데이터가 발생되는 시간에 따라 파티셔닝을 할 것인지를 설명된 기준에 따라 적용하면 된다.
