관계형 데이터베이스 조회와 쓰기 trade-off 1

관계형 데이터 베이스에서 항상 고민해줘야 하는 부분들에 대해 알아보자..

 

조회와 쓰기는 성능 관점에서 모두가 좋아지도록 만들 수 없다..

 

지금부터 하나 씩 알아보도록 하겠다.

 

1. 데이터베이스 정규화/비정규화

중복을 최소화하게 데이터를 구조화하는 프로세스를 정규화(Normalization)라고 한다.

 

비유를 통해 알아보겠다.

 

우리가 소설을 쓴다고 생각해보자..

 

[A 상황]

1. 주인공의 이름이 김찬호인 300 Page 에 달하는 소설을 다 썻다.

2. 그런데 갑자기 주인공 이름을 손인욱이라는 이름으로 변경해야 할 상황이 생겼다.

3. 그러면 우리는 하나하나 모든 주인공 이름이 적힌 곳을 찾아가서 변경해줘야 할 것이다.

(툴의 도움을 받지 않는다고 가정)

 

이번엔 두번째 상황을 보자

[B 상황]

1. 주인공의 이름이 김찬호인 300 Page 에 달하는 소설을 다 썻다.

-> 여기서 우리는 소설에 바로 김찬호라고 박아놓지 않고 {이름설정.주인공} 이라고 쓰고

-> 이름설정 이라는 설정 책을 만들어 놓았다.

2. 그런데 갑자기 주인공 이름을 손인욱이라는 이름으로 변경해야 할 상황이 생겼다.

3. 그러면 우리는 소설은 변경할 필요가 없고 단순히 이름설정 책에 이름설정.주인공 변수를 김찬호에서 손인욱으로 변경하면 그만이다.

 

A 상황과 B 상황을 비교하면 데이터 정규화가 무엇인지 쉽게 알 수 있다.

중복 데이터를 한 곳으로 몰아서 주인공 이름이 변경되는 상황에서 쉽게 대처가 가능하였다.

 

따라서 아래와 같이 정리 할 수 있다.

 

정규화

1. 데이터의 중복을 제거하고 한 곳에서 관리

2. 데이터 정합성 유지가 쉽다.

3. 읽기(조회)시 참조가 발생

 

비 정규화

1. 중복을 허용한다.

2. 데이터 정합성 유지가 어렵다.

3. 참조없이 조회 가능

 

즉...

정규화는 쓰기의 성능을 극대화 한 설계이고

비 정규화는 조회의 성능을 극대화 한 설계이다.

-> 서로의 성능을 깎아먹는다는 것을 알 수 있음 -> trade-off

-> 대용량 시스템 설계 시,

-> CQRS 패턴 도입 할 때 Command 와 Query 관점에서 각각을 생각 해 볼 수 있을 것이다.

-> 혹은 조회와 쓰기의 사용 빈도를 생각하여 고민해 볼 수 있다.

 

 

백엔드 실무에서 고민 포인트

웹 서비스에서는 조회의 비율이 쓰기 비율 보다 압도적으로 높다.

 

1. 데이터의 최신성 보장 시간 (얼마나 빠르게 보장할 것인지..)

-> 데이터 일관성과 최신성을 덜 보장해도 된다면, 정규화 하지 않고 조회 성능을 가져갈 수 있음

 

2. 히스토리성 데이터는 정규화 X

 

3. 데이터 CUD 비율과 R 비율

-> CUD 비율보다 R 비율이 높으면 비 정규화가 유리

 

4. 객체 탐색 깊이

-> 탐색 깊이가 깊을 수록 Join이 중첩되어 조회 성능이 안 좋아진다.

 

5. 정규화를 하기로 했다면.. 조회는?

-> 보통 Join을 이용하는데 Table의 결합도를 높이므로 고민해 볼 필요가 있음..

-> 그래서, 캐시 기법이 많이 사용된다.

(캐시를 도입하기로 했다면, 만료 정책과 캐시 히트율을 잘 생각해보자)