제4절 대량 데이터에 따른 성능

1. 대량 데이터발생에 따른 테이블 분할 개요
   

• 설계가 잘되어 있는 데이터 모델이라고 하더라도 대량의 데이터가 하나의 테이블에 집약되어 있고 하나의 하드웨어 공간에 저장되어 있으면 성능저하를 피하기가 힘들다
• 특정 테이블에 있는 경우에 발생이 되는데 이런 경우 트랜잭션이 분산 처리될 수 있도록 테이블 단위에서 분할의 방법을 적용할 필요가 있는 것이다.

• 아래는 성능 저하 유발 사례
• 한 테이블에 데이터가 대량으로 집중되거나 하나의 테이블에 여러 개의 칼럼이 존재하여 디스크에 많은 블록을 점유하는 경우
• 하나의 테이블에 대량의 데이터가 존재하는 경우에는 인덱스의 Tree구조가 너무 커져 효율성이 떨어져데이터를 처리(입력, 수정, 삭제, 조회)할 때
• 한 테이블에 많은 수의 컬럼이 존재하게 되면 데이터가 디스크의 여러 블록에 존재하므로 인해 디스크에서 데이터를 읽는 I/O량이 많아지게 되어 성능 저하 발생
• 대량의 데이터가 하나의 테이블에 존재하게 되면 인덱스를 생성할 때 인덱스의 크기가 커지게 되고 그렇게 되면 인덱스를 찾아가는 단계가 깊어지게 되어 조회의 성능에도
  영향을 미치게 된다.
• 한 테이블에 많은 수의 컬럼(ex:300개 이상)을 가지고 있는 경우, 로우 길이가 너무 길어서 데이터 블록 하나에 저장되지 않고 여러 개에 걸쳐 하나의 로우가 저장되는 로우체이닝(Row Chaining), 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장되는 로우마이그레이션(Row Migration) 현상이 발생하게 된다. 두
  현상이 발생하여 많은 블록에 데이터가 저장되면 데이터베이스 메모리, 디스크 입출력이 발생할 때 불필요하게 I/O가 많이 발생하여 성능이 저하된다.

1. 한 테이블에 많은 수의 컬럼을 가지고 있는 경우
   

– 트랜잭션이 독립적으로 발생되는 경우, 위 그림처럼 분리하게 되면 로우체이닝과 로우마이그레이션이 줄어들게 되고 디스크 I/O가 줄게 되어 성능이 개선되게 된다.

1. 대량 데이터 저장 및 처리로 인한 성능
   

• 테이블에 많은 양의 데이터가 예상될 경우 파티셔닝을 적용하거나 PK에 의해 테이블을 분할하는 방법을 적용할 수 있다.
• Oracle의 경우 크게 LIST PARTITION(특정값 지정), RANGE PARTITION(범위), HASH PARTITION(해쉬적용), COMPOSITE PARTITION(범위와 해쉬가 복합) 등이 가능하다.
• 데이터량이 몇 천만건을 넘어서면 아무리 서버사양이 훌륭하고 인덱스를 잘 생성해준다고 하더라도 SQL문의 성능이 나오지 않는다.

  가. RANGE PARTITION 적용
  

  • 다음은 요금테이블에 PK가 요금일자+요금번호로 구성되어 있고 데이터건수가 1억2천만 건인 대용량 테이블의 경우이다. 하나의 테이블로는 너무 많은 데이터가 존재하므로 인해 성능이 느린 경우에 해당된다. 이 때 요금의 특성상 항상 월단위로 데이터 처리를 하는 경우가 많으므로 PK인 요금일자의 년+월을 이용하여 12개의 파티션 테이블을 만들었다. 하나의 파티션 테이블당 평균 1,000만 건의 데이터가 있다고 가정한다.

    

  • 1000만건의 데이터가 있다 해도 SQL문의 Where절에 비교된 요금일자에 의해 각 파티션에 있는 정보를 찾아가므로 성능 개선이 이루어질 수 있다.
  • 가장 많이 사용하는 파티셔닝, 대상 테이블이 날짜 또는 숫자값으로 분리가 가능하고 각 영역별로 트랜잭션이 분리된다면 추천.
  • 데이터보관주기에 따라 테이블 데이터를 쉽게 지우는 것이 가능하므로 테이블 관리가 용이.

  나. LIST PARTITION 적용
  

  • 핵심적인 코드값 등으로 PK가 구성되어 있고 대량의 데이터가 있는 테이블에 추천
  • LIST PARTITION은 대용량 데이터를 특정값에 따라 분리 저장할 수는 있으나 RANGE PARTITION과 같이 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.

  

  다. HASH PARTITION 적용
  

  • 지정된 HASH 조건에 따라 해싱 알고리즘이 적용되어 테이블이 분리되며 설계자는 테이블에 데이터가 정확하게 어떻게 들어갔는지 알 수 없다.
  • 성능향상을 위해 사용하며 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.

1. 테이블에 대한 수평분할/수직분할의 절차
   
2. 데이터 모델링을 완성한다.
   
3. 데이터베이스 용량산정을 한다.
   
4. 대량 데이터가 처리되는 테이블에 대해서 트랜잭션 처리 패턴을 분석한다.
   
5. 컬럼 단위로 집중화된 처리가 발생하는지, 로우단위로 집중화된 처리가 발생되는지 분석하여 집중화된 단위로 테이블을 분리하는 것을 검토한다.
   

• 테이블 용량산정의 경우, 컬럼이 너무 많지 않은지 확인한다.
• 트랜잭션 단위로 나뉘어진다면 1:1로 테이블을 분리할 수 있는지 검증한다.
• 컬럼의 수가 적지만 데이터용량이 많아 성능저하가 예상이 되는 경우 파티셔닝 전략을 고려한다.