본문 바로가기
Database

테이블마다 id 칼럼을 PK로 사용한 이유는 무엇일까?

by Jammini 2024. 2. 14.
728x90

 

 

목차

  1. 개요
  1. 설계 테이블
  1. 사용한 이유와 장점
  1. 결론

1. 개요

프로젝트 테이블을 설계하고 리뷰를 받는중 아래와 같은 질문을 받았다.

Q) 각각의 테이블에 auto increment 되는 id 칼럼을 사용한 이유와 했을때의 장점이 무엇인가요?

A) 어,,, 엄,,, 관용적으로 많이 사용해서 자연스럽게 id를 PK로 사용했습니다.

 

질문을 받은 나는 대답을 제대로 하지 못하였고 테이블을 왜그렇게 설계했는지보단 관용적으로 이렇게 많이들 사용한다고 해서 자연스럽게 테이블을 설계했던 것이었다.

 

'설계를 왜 이렇게 했는가?' 에 대해서 고민하고 설계를 해야 하는데 이번을 계기로 많은 사람들이 왜 id칼럼을 auto increment가 되는 칼럼으로 사용했을때 장점에 대해 정리를 해보려고 한다.

2. 설계 테이블

내가 설계한 테이블은 위와 같았다.

 

각각의 테이블에는 id값을 가지고 있는 테이블이다. 여기서 User 테이블을 자세히 살펴보자.

 

User테이블에는 user_id라는 칼럼이 uniquekey이므로 PK로 사용해도 무방한 것을 볼 수 있다.

 

그럼에도 불구하고 왜 각 테이블의 id칼럼을 PK로 사용하였을까?

3. 사용한 이유와 장점

1. 일관성

각각의 테이블마다 PK로 id값을 가지고 있다보니 일관성이 생긴다.

 

만약 User 테이블에서 user_id가 PK이고 Category 테이블에서 name이 PK였다면 각각의 테이블의 PK를 알아 내기 위해 테이블을 확인하거나 체크가 필요할 것이다.

 

또한, 실제로 데이터를 조회할 때 User가 몇명인지 파악할때 쉽게 파악이 가능하다. 예를 들어 User테이블을 조회했는데 id값이 5000몇의 id값이 나온다면 간단하게 ‘5000명정도의 유저가 있구나’ 라고 쉽게 파악이 가능하다.

2. 효율성

MySQL은 PK를 설정하면 해당 값을 Index로 잡아 데이터를 B-tree구조로 저장한다.

 

2-1. 정렬된 데이터

B-tree는 데이터를 정렬된 상태로 유지하는데, id 칼럼이 자동 증가하는 숫자라면 삽입 되는 데이터가 자연스럽게 정렬된 순서로 추가된다.

이는 B-tree 인덱스가 정렬된 상태를 유지하는데 유리하며, 삽입 성능을 최적화할 수 있다.

 

2-2. 균형 유지

B-tree는 균형트리로 설계되어, 삽입, 삭제, 검색 시 트리의 균형을 유지한다. id 칼럼이 자동 증가하는 순서로 삽입되면 트리의 균형을 유지하는 데 있어 추가적인 비용이 줄어들 수 있다. 왼쪽과 오른쪽 노드의 밸런스를 유지하며 O(logN)의 시간복잡도를 보장한다.

즉, 불규칙한 데이터를 삽입할 때보다 성능 저하가 덜 발생한다.

 

2-3. 인덱스 재구성 최소화

데이터베이스 테이블에 데이터가 삽입될 때, 만약 기본 키가 자동 증가하는 id 칼럼이라면 B-tree 인덱스는 새로운 데이터를 트리의 오른쪽 끝에 삽입하게 된다. 이 과정에서 기존 인덱스를 재구성할 필요가 거의 없으므로 인덱스 유지 관리 비용이 줄어든다.

3. 확장성

우리의 프로젝트가 정말 잘되어서 데이터가 수백만, 수천만 데이터가 쌓였다고 하자. 그런 경우 나중에 샤딩이나 아니면 파티셔닝 같이 이런 것들을 고민하게 된다. 이때 데이터를 쪼개고 나눈다고 했을 때에도 그 기준을 뭘로 할지에 대한 기준.

 

즉, 각각의 테이블이 id별로 순차적으로 쌓여있으니 오래된 사용자인지, 최근에 가입한 사용자인지에 대한 판단을 번호로 쉽게 구분을 할 수 있다는 것이다.

4. 결론

리뷰로 질문 받았던 내용에 대해 정리하면서 id값을 PK로 사용했을 경우 장점에 대해 전반적으로 정리할 수 있었다.

 

요약하면, 다음과 같이 정리할 수 있다.

1. 각각의 테이블 간에 데이터 일관성을 유지하기 쉽다. 데이터가 중복되거나 혼동될 가능성이 줄어든다.

2. 정수형 id 칼럼은 비교적 작은 크기를 가지고 있어 인덱싱 및 조회 성능이 우수하다. 즉, 조회속도나 DB 작업 속도가 향상 된다.

3. 특히, 대규모 데이터베이스에서 중요한 장점으로 작용한다. 추후 샤딩이나 파티셔닝 같이 데이터를 쪼개고 나눌때 등등 효과적이다.

 

앞으로도 설계를 하면서도 ‘관용적으로 이렇게 많이 사용하니까’ 가 아닌 '왜 이렇게 사용했는지 이유를 고민하고 설계를 하도록 하자.

참고

 

반응형

'Database' 카테고리의 다른 글

논리적삭제 vs 물리적삭제  (0) 2024.06.20
SQL Mapper vs ORM 기술  (0) 2024.06.19
SELECT * 을 쓰면 안되는 이유  (1) 2023.11.29
MySQL 실행계획이란?  (0) 2023.11.20
공유 락(shared lock) vs 배타 락(exclusive lock)  (0) 2023.11.16