SQLD 2-4 ] 대량 데이터에 따른 성능

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

 

  - 대량의 데이터가 처리되는데 테이블에 성능이 저하되는 이유는 SQL 문장에서 데이터를 처리하기 위한

    I/O 의 양이 증가하기 때문. 인덱스를 적절하게 쓰면.. I/O 는 줄일 수 있지만, 대량의 데이터가

    하나의 테이블에 존재하게 되면.. 성능저하를 유발할수 있다.

 

 

로우체이닝 : 로우 길이가 너무 길어 데이터 블록 하나에 다 저장못하고 두 개 이상의 블록에 걸쳐 하나의 데이터가 저장

로우마이그레이션 : 블록에서의 수정이 발생되면 수정된 데이터를 그 블록에 저장못하고 다른 블록의 빈공간에 저장하는거

 

 

 

 

❏ 한 테이블에 많은 수의 칼럼을 가지고 있는 경우

 

 

저렇게 많은 칼럼들을 다 가져오려면... 디스크 I/O가 엄청많이 일어나겠지

해결법으로는 1:1 관계로 분리하였다

 

 

 

 

 

 

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

 

  - 데이터 양이 몇 천만건을 넘어서면 아무리 서버사양이 좋고 인덱스를 잘 해놨다고 해도... 성능이 안나올수있다.

     이럴때에는 논리적으로는 하나의 테이블로 보이지만 물리적으로는 여러개의 테이블로 쪼개어 저장한다.

    

1. RANGE PARTITION 적용

 

범위 파티션. 말그대로 범위 별로 파티셔닝을 한 것. 

SQL 문장을 처리할때는 마치 하나의 테이블처럼 보이지만, DBMS 내부에서는 SQL WHERE 절에 비교된

'요금일자' 에 의해 각 파티션에 있는 정보를 찾아가서 성능이 개선된다.

 

가장 많이 사용하고, 테이블이 날짜 또는 숫자값으로 분리가 된다면 이 범위파티션을 적용하자!

또, 데이터를 쉽게 지울수 있어 관리가 용이하다.

 

2. LIST PARTITION 적용

 

 

 

테이블에 접근하면 내부적으로 파티셔닝 되는건 같은데, 무슨 차이가 있을까.

1번 범위 파티견은 요금 특성상 월 단위로 데이터처리를 하는게 많은 편이여서,

날짜 단위인 범위로 만들고. 지금 2번 리스트 파니셔닝은 그런 범위 느낌이 아니라

단일. 예를들어 "지역!" 이렇게 딱딱한 리스트 별로 파티셔닝을 한다.

대신 범위 파티션처럼 데이터를 쉽게 지울수 있는 기능은 없다...

 

 

3. HASH PARTITION

지정된 HASH 조건에 따라 알고리즘이 적용되어 테이블이 분리되서 설계자는 어떻게 데이터가 들어갔는지

내부적으로 알 수 없다. 성능향상을 위해 사용하고, 리스트 파티션같이 데이터를 쉽게 지울수 있는 기능이 없다..

 

 

 

 

❏  테이블에 대한 수평분할 / 수직분할의 절차

 

 1. 데이터 모델링을 완성한다.

   - 넵

 2. 데이터베이스 용량산정을 한다.

   - 용량 체크가 끝나면 사이즈가 나오겠지

 3. 대량데이터가 처리되는 테이블에 대해서 트랜잭션 처리 패턴을 분석한다.

   - 체크 끝나고 데이터가 많이 처리되는 테이블을 가서 한번 살펴봤더니

 4. 칼럼단위로 집중화된 처리가 발생하는지, 로우단위로 집중화된 처리가 발생되는지 분석하여 집중화된

     단위로 테이블을 분리하는 것을 검토한다.

   - 칼럼의 수가 너무 많으면 아까 설명한 테이블을 1:1로 분리할수있는지 보고,

     많지는 않지만 데이터용량이 많으면 파티셔닝을 고려하면 된다!