SQLD - 과목1. (9) 대량 데이터에 따른 성능

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

 

설계가 잘 된 데이터 모델이어도 대량의 데이터가 하나의 테이블에 집약되어, 하나의 하드웨어 공간에 저장되어 있으면 성능이 저하된다.

일의 처리되는 양이 몰리는 현상은, 어떤 업무에 있어서 중요한 업무에 해당되는 데이터가 특정 테이블에 있는 경우에 발생이 된다.

트랜잭션이 분산 처리가 될 수 있도록 테이블 단위에서 분할의 방법을 적용한다.

 

 

 

 

 

▷ 수평/수직 분할

 

테이블 수평/수직 분할에 의한 성능 상향

 

 

 

 

 

 

◈ 하나의 테이블에 대량의 데이터가 존재하는 경우

 :  인덱스의 Tree 구조가 너무 커져 효율성이 떨어져 데이터를 처리 ( 입력, 수정, 삭제, 조회 ) 할 때 디스크 I/O 를 많이 유발한다.

 

◈ 하나의 테이블에 많은 수의 칼럼이 존재하는 경우

 :  데이터가 디스크의 여러 블록에 존재하므로, 디스크에서 데이터를 읽는 I/O 량이 많아지게 되어 성능이 저하된다.

 

 

---

 

∴ 대량의 데이터가 처리되는 테이블에 성능이 저하되는 이유

   : SQL 문장에서 데이터를 처리하기 위한 I/O 량이 증가하기 때문이다.

 

 

◈ 잘못된 대안법 < 인덱스 >

 -  인덱스를 적절하게 구성하여 I/O 를 줄인다. ( X )

 -  조회 조건에 인덱스를 적절하게 이용하여 원하는 데이터만 접근하면 I/O 량이 그다지 증가하지 않는다. ( X )

 

 -  인덱스를 생성할 때 인덱스의 크기(용량)이 커진다.

 -  인덱스를 찾아가는 단계가 깊어지게 되어 조회의 성능이 저하된다.

 -  입력/수정/삭제 하는 트랜잭션의 경우 인덱스의 특성상 일량이 증가하여 더 많이 성능이 저하된다.

 -  데이터에 대한 범위 조회시, 더 많은 I/O 유발을 하여 성능이 저하된다.

 

 -  칼럼이 많아지면, 물리적인 디스크에 여러 블록에 데이터가 저장된다.

 -  따라서 데이터를 처리할 때 여러 블록에서 데이터를 I/O 해야한다. ( SQL 문장의 성능이 저하된다. )

 -  대량 데이터를 가진 테이블에서 불필요하게 많은 양의 I/O 를 유발하여 성능이 저하된다.

    → 기술적으로 분석하여 성능을 향상하는 방법으로 분할할 수 있다.

 

 

 

 

디스크에 데이터 저장의 개념

 

 

 

---

 

 

 

◈ 성능 저하 원인

 :  많은 칼럼은 로우체이닝과 로우마이그레이션이 많아지게 되어 성능이 저하된다.

    로우체이닝과 로우마이그레이션이 발생하여 많은 블록에 데이터가 저장되면 데이터베이스 메모리에서 디스크와 I/O 가 발생할 때 

    불필요하게 I/O 가 많이 발생하여 성능이 저하된다.

 

 

 

 

  ① 로우체이닝 ( Row Chaining )

       :  Row 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고,

          두 개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태.

 

 

  ② 로우마이그레이션 ( Row Migration )

       :  데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고,

          다른 블록의 빈 공간을 찾아 저장하는 방식.

 

 

 

 

 

 

 

 

 

 

 

---

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

 

한 테이블에 칼럼수가 아주 많을 경우, 앞쪽과 중간에 위치한 칼럼의 정보를 가져오려면 물리적으로 칼럼의 값이 블록에 넓게 산재되어 있어서 디스크 I/O 가 많이 일어난다.

 

 

칼럼수가 많은 테이블

 

 

이렇게 많은 칼럼을 가지고 있는 테이블에 대해서는 트랜잭션이 발생될 때 어떤 칼럼에 대해 집중적으로 발생하는지 분석하여 테이블을 쪼개어 주면 디스크 I/O 가 감소하게 되어 성능이 개선되게 된다.

 

 

 

 

칼럼수가 많은 테이블의 1:1 분리

 

 

 

 

위 그림에서 ' 전자출판 ' 유형과 ' 대체제품 ' 유형의 트랜잭션이 각각 독립적으로 발생하는 경우가 많이 있어서 1:1 관계로 분리했다.

테이블의 분리로, 디스크에 적어진 칼럼이 저장되므로 로우마이그래이션과 로우체이닝이 많이 줄어들 수 있다.

 

따라서 정보를 가져오는 동일한 SQL 구문에 대해서도 디스크 I/O 가 줄어들어 성능이 개선된다.

 

∴ 트랜잭션을 분석하여 적절하게 1:1 관계로 분리함으로써 성능 향상이 가능하도록 해야 한다.

 

 

 

 

 

칼럼수가 많은 테이블의 1:1 분리의 I/O

 

 

 

 

 

 

---

3. 대량 데이터 저장 및 처리로 인해 성능

 

테이블에 많은 양의 데이터가 예상될 경우, 파티셔닝을 적용하거나 PK 에 의해 테이블을 분할하는 방법을 적용한다.

 

Oracle 의 경우,

LIST PARTITION (특정값 지정) / RANGE PARTITION (범위) / HASH PARTITION (해쉬 적용) / COMPOSITE PARTITION (범위와 해쉬가 복잡) 등이 가능하다.

 

몇 천만건을 넘어서는 데이터량이면, 서버사양이 훌륭해도 SQL 문장의 성능이 좋지 않다.

물리적으로 여러 개의 테이블스페이스에 쪼개어 저장될 수 있는 구조의 파티셔닝을 적용하도록 한다.

 

 

 

 

---

① RANGE PARTITION 적용

 

하나의 테이블로는 너무 많은 데이터가 존재하므로 인해 성능이 느린 경우에 해당된다.

하나의 테이블보다 DBMS 내부적으로, SQL WHERE 절에 비교된 데이터에 의해 각 파티션에 있는 정보를 찾아가므로 평균 1,000만 건의 데이터가 있는 곳을 찾아도 성능이 개선될 수 있다.

 

 

▷ RANGE PARTITION

    : 가장 많이 사용하는 파티셔닝의 기준이다.

      대상 테이블이 날짜 또는 숫자 값으로 분리가 가능하다.

      각 영역별로 트랜잭션이 분리된다면 사용한다.

      데이터 보관 주기에 따라 테이블에 데이터를 쉽게 지우는 것이 가능하므로 ( 파티션 테이블을 DROP 하면 되므로 )

      데이터보관주기에 다른 테이블 관리가 용이하다.

 

 

파티셔닝의 적용 - RANGE

 

 

---

② LIST PARTITION 적용

 

핵심적인 코드값 등으로 PK 가 구성되어 있고, 대량의 데이터가 있는 테이블이라면 값 각각에 의해 파티셔닝이 되는 LIST PARTITION 을 적용한다.

 

 

▷ LIST PARTITION

    : 대용량 데이터를 특정 값에 따라 분리/저장 할 수는 있으나,

     RANGE PARTITION 과 같이 데이터 보관 주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.

 

 

 

파티셔닝의 적용 - LIST

 

 

---

② HASH PARTITION 적용

 

 

▷ HASH PARTITION

    : 지정된 HASH 조건에 따라 해슁 알고리즘이 적용되어 테이블이 분리되며,

      설계자는 테이블의 데이터가 정확하게 어떻게 들어갔는지 알 수 없다.

      성능향상을 위해 사용한다.

      데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.

 

 

 

---

 

∴ 데이터량이 대용량이 되면 파티셔닝의 적용은 필수적으로 파티셔닝 기준을 나눌 수 있는 조건에 따라 적절한 파티셔닝 방법을 선택하여 성능을 향상 시킨다.

 

 

 

 

 

 

 

 

---

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

▷ 수평분할 / 수직분할 4가지 원칙

 

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

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

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

(4) 칼럼 단위로 집중화된 처리가 있는지, 로우단위로 집중화된 처리가 발생되는지, 분석하여 집중화된 단위로 테이블을 분리한다.

 

 

* 용량산정 : 어느 테이블에 데이터의 양이 대용량이 되는지 분석하는 것.

 

* 칼럼의 수가 많은 경우, 트랜잭션의 특성에 따라 테이블을 1:1 형태로 분리할 수 있는지 검증한다.

* 칼럼 수가 적지만 데이터 용량이 많아 성능 저하가 예상이 되는 경우, 테이블에 대해 파티셔닝 전략을 고려한다.

* 임의로 파티셔닝을 할 것인지, 데이터가 발생되는 시간에 따라 파티셔닝을 할 것인지를 기준에 따라 적용한다.

 

 

 

 

 

 

 

 

 

 

 

---