코딩하는 오징어

데이터 모델링에서 정규화의 의의와 성능 논쟁 본문

알쓸신잡

데이터 모델링에서 정규화의 의의와 성능 논쟁

코딩하는 오징어 2020. 1. 5. 15:43
반응형

2020/01/05 - [알쓸신잡] - 데이터 모델링의 정규화

 

위의 글에서 정규화에 대해서 소개하였다. 이번 글에서는 정규화를 하는 행위가 어떤 의미를 갖는지 알아보자.

 

정규화 모델은 다음과 같은 중요한 특징을 가진다. 이를 보면 데이터 모델링의 핵심 이론이 왜 정규화 이론이어야 하는지 자연스럽게 이해될 것이다.

 

1. 속성간의 종속성을 기준으로 성격이 유사한 속성들은 모이고 관계없는 속성들은 분리된다. 즉, 속성들이 자연스럽게 자기 자리를 찾게 되면서 데이터 집합의 범주화가 이루어진다.

 

2. 하나의 주제로 집약된 데이터 구조, 제대로 된 엔터티가 도출된다. 정규화는 함수 종속을 없애고 밀접한 속성을 하나의 표에 집약시키는 체계적인 방법이다. 따라서 데이터는 응집도는 높고 결합도는 낮게 분리된다.

 

3. 데이터 중복이 최소화된 효율적이고 구조화된 모델이 나온다. 중복에 따른 데이터 이상 현상이 사라지며, 저장 용량 측면에서도 이익을 보게된다.

 

4. 데이터 간의 종속성을 분석하기 때문에 엔터티명과 더불어 엔터티의 정체성을 가장 잘 표현하는 주 식별자가 정확히 도출된다. 주 식별자는 인스턴스를 구분하는 기준이므로, 집합의 개체 발생 규칙도 검증되어 더 정확해진다.

 

5. 업무 변경에 따른 확장성이 좋아진다.

 

6. 데이터 무결성을 극대화한다.

 

7. 정규화된 모델은 그렇지 않은 모델에 비해 대부분 성능이 좋다.

정규화와 관련된 성능 논쟁

  • 정규화를 하면 테이블이 늘어나 조인(Join)이 증가하는 등 "정규화 = 성능 저하"라고 생각할 수 있다. 필자도 데이터 모델링에 대해 공부하기 전까지 그렇게 생각하여 반정규화를 고민하기도 하였다.(물론, 상황에 따라 정규화 한 것을 역정규화하는 과정도 필요하다.)

 위의 그림에서 (A)는 주 식별자를 구성하는 <지점코드>와 <등록자ID> 중 <지점코드>에 부분 종속된 속성이 존재하여 2정규화가 필요한 테이블이고, (B)는 이를 2정규화하여 두개의 테이블로 분리한 모습이다. "2002년 이후에 등록한 모든 지점을 조회하라"는 SQL을 처리하면 정규화된 쪽이 훨씬 빠르다. (A)는 불필요하게 중복된 <등록자ID>만큼의 데이터를 더 읽어야 하지만, (B)는 <지점> 테이블에서 조건에 맞는 데이터만 읽어 빠르게 처리할 수 있다. <등록유형코드>가 "01"인 등록원장 정보를 <지점명>과 함께 조회하는 경우를 생각해보자. (A)는 하나의 테이블에서 조회할 수 있지만, 오른쪽은 테이블 두 개를 조인해야 한다. 하지만 <지점>과 <등록원장>의 연결 고리인 <지점코드> 인덱스만 정확히 정의되어 있다면 성능상의 차이는 미미할 것이다.

 

 대부분의 DBMS는 데이터를 블록(페이지) 단위로 읽고 쓴다. 하나의 블록에는 다수의 행(개체)이 포함될 수 있다. (A)와 같이 데이터가 모델링이 되어있을때 하나의 개체 크기가 2KB, 한 블록의 크기가 8KB라고 가정하자. 그렇다면 하나의 블록(페이지)에는 4개의 개체가 담길 수 있다. "코딩하는 오징어의 블로그"라는 하나의 지점만 조회하려 해도 DBMS는 한 블록(페이지), 즉 8KB를 메모리로 올린다. IO의 최소 단위가 블록이기 때문이다. SQL을 최적화할 때 조회할 레코드의 수가 아닌 블록의 수에 집착하는 이유도 바로 이 때문이다. 테이블을 정규화한 (B)와 같은 모델에서는 지점 엔터티의 하나의 개체 크기는 1KB라고 가정하면, 한 번의 IO결과로 8개의 개체를 메모리에 올릴 수 있다. 따라서 캐시 적중률(hit ratio)이 높아짐에 따라 성능이 더 좋아 질 수 있다. 이처럼 정규화가 잘 되어 있다면 훨씬 적은 블록을 읽고도 원하는 결과를 얻을 수 있다.

 

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

 

참고 서적: 프로젝트 성패를 결정짓는 데이터 모델링 이야기

 

반응형

'알쓸신잡' 카테고리의 다른 글

Redirect 와 Forward  (2) 2020.04.27
OLTP와 OLAP  (1) 2020.01.05
데이터 모델링의 정규화  (1) 2020.01.05
Timeout에 관한 정리  (0) 2019.03.19
HikariCP 세팅시 옵션 설명  (0) 2018.10.02
Comments