ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 데이터 모델링12 - 정규화와 성능, 실무에서 모델링 절차
    Data Base/관계형 데이터 모델링 2023. 9. 20. 15:55

    정규화와 성능

    [그림 7-8] 정규화 전(왼쪽)과 후(오른쪽), 어느 쪽이 빠른가?

    [그림 7-8]의 왼쪽은 주 식별자를 구성하는 <지점코드>와 <등록자ID>중 <지점코드>에 부분 종속된 속성이 존재하여 2정규화가 필요한 테이블이고, 오른쪽은 이를 2정규화하여 두 개의 테이블로 분리한 모습이다. '2002년 이후에 등록한 모든 지점을 조회하라'는 SQL을 처리하면 정규화된 쪽이 훨씬 빠르다. 왼쪽 모델의 경우는 불필요하게 중복된<등록자ID>마큼의 데이터를 더 읽어야 하지만, 오른쪽은 <지점>테이블에서 조건에 맞는 데이터만 읽어 빠르게 처리할 수 있기 때문이다.

     

    반대로 <등록유형코드>가 '01' 등록원장 정보를 <지점명>과 함께 조회하는 경우를 생각해보자 왼쪽 테이블은 하나의 테이블에서 조회할 수 있지만, 오른쪽은 테이블 두개를 조인해야 한다. 하지만 <지점>과 <등록원장>의 연결 고리인 <지점코드>인덱스만 정확히 정의되어 있다면 성능상의 차이는 미미할 것이다.

     

    일단은 단편적인 예로 정규화로 테이블 수와 조인의 양이 늘어난다고 해서 성능이 무조건 저하되는 것은 아님을 알 수 있다.

     

    [그림7-9] 정규화로 개체 크기가 작아져서 성능 향상을 기대할 수 있는 경우

    대부분 DBMS는 데이터를 블록 단위로 읽고 쓴다. (DBMS에 따라 '페이지'라고도 한다.) 하나의 블록에는 다수의 행(개체)이 포함될 수 있다. 하나의 블록에는 다수의 행(개체)이 포함될 수 있다.  (앞으로의 예시는 이해를 돕기 위해 많은 부분이 단순화 되었다.) 예시를 위해 가정을 하자면  [그림 7-9]의 왼쪽 위의 <고객> 테이블 구조에서 한 행이 2K고 한 블록의 크기가 8K라면 한 블록에 4개의 개체를 담을 수 있다.  즉 한 사람의 <고객분류코드>만 조회하려 해도 DBMS는 한 블록, 즉 8K를 메모리에 올린다. IO의 최소 단위가 블록이기 때문이다. SQL을 최적화할 때 죄회할 레코드의 수가 아닌 블록의 수에 집착하는 이유도 바로 이때문이다.

     

    각설하고, [그림 7-9]의 오른쪽 아래 처럼  <고객>테이블을 정규화해서 <주소> 정보를 분리했더니 고객 한 명의 레코드가 1K 줄었다고 가정하자. 그렇다면 블록 하나가 이전보다 두 배나 많은 개체를 포함할 수 있게 된다. 이는 정규화가 IO의 대상이 되는 블록 수를 줄여줄 수 있음을 의미한다. where 절을 만족하는 집합을 디스크에서 메모리로 퍼오기 위해 기존에 20개의 블록을 읽어야 했다면, 이제는 그 절반인 10개만 읽으면 된다. 뿐만 아닌라 한 블로에 더 많은 개체가 존재하면 메모리에 한 번 올라간 블록이 다시 사용될 확률도 그만큼 높아진다. 즉, 적중률(hit ratio)이 좋아진다.

     

    정규화를 하면 테이블이 분리되어 조인이 늘어나 성능이 저하된다느 말은 상황에 따라 사실일 수도 있고 아닐 수도 있다. OLTP에서 조인에 의한 성능 저하가 극심한 경우라면 조인의 방법이 잘못 되었을 가능성이 크다. 인덱스가 없거나 도인 *조인 연결 고리 이상 으로 옵티마이저가 인덱스를 사용하지 못하는 등의 문제이지, 조인 자체가 문제의 본질인 경우는 드물다. 다만 분리된 테이블들이 일부 트랜잭션에서 성능을 떨어트리기도 하고 조인 자체에서도 아주 미미한 부하가 있을 수 있다는 점도 명심한다.

     

    *조인 연결 고리 이상 : 조인 연결고리에 해당하는 두 테이블의 컬럼 중 한 곳에 인덱스가 없거나, 인덱스가 있음에도 컬럼 변형 등으로 인해 인덱스를 사용할 수 없는 상황을 말한다.

    💡tip) 옵티마이저(Optimizer)

    옵티마이저는 가장 효율적인 방법으로 SQL을 수행할 퇴적의 처리 경로를 생성해주는 DBMS의 핵심 엔진이다. 컴퓨터의 두뇌가 CPU인 것처럼 DBMS의 두뇌는 옵티마이저라고 할 수 있다. SQL문을 실행하면 소프트웨어 실행 파일처럼 즉시 실행 되는 것이 아니라 옵티마이저라는  곳에 해당 쿼리문을 어떻게 실행 시킬지에 대한 계획을 세우게된다.  이렇게 실행계획을 세운 뒤 시스템 통계정보를 활용하여 각 실행계획의 예상 비용을 산정한 후 각 실행계획을 비교해서 최고의 효율을 가지고 있는 실행계획을 판별한 후 그 실행계획에 따라 쿼리를 수행하게 되는 것이다.   

     

    실무에서의 모델링 절차

    정규화를 차례대로 살펴봤기때문에 혹여나 오해의 여지가 있을 수 있지만, 실무에서 정규화는 1정규화 완료 후 2,3정규화 순차적으로 진행되지 않는다. 정규화 이론을 정확이 이해하고 내재화 한다면, 모델링 대상에 대해 종합적인 판단을 해 한번에 잘 구조화된 정규형 모델에 도달할 수 있다. 이때 판단 기준이 되는 것은 당연히 정규화 이로니다.

     

    정규화 이론을 내재화했다는건 단순 개념을 암기한 수준에서 그치는 것이 아니라 현업에서 관리해야 하는 데이터의 현산과 발생 규칙을 이해해 그것을 정규화 이론을 기반으로 해석하는 능력이 있음을 의미한다. 다시 한번 정리해 말하자면 정규화를 안다는 것은 데이터의 종속성을 정확히 이해하고 그 관점으로 모델링을 전개한다는 뜻이다.

     

     

    [출처 - 프로젝트의 성패를 결정짓는 데이터 모델링 이야기 , 김상래 저]

    댓글

Designed by Tistory.