Primary key 생성 전략

분산 데이터베이스 환경에서는 PK를 어떻게 생성하면 좋을까?

나는 당연히 auto_increment가 간단하고 좋을 것이라고 생각했다.

 

후보

• DB auto_increment
• 유니크 문자열 or 숫자
• 유니크 정렬 문자열
• 유니크 정렬 숫자

---

DB auto_increment

문제점

1. 분산 데이터베이스 환경에서 DB auto_increment를 쓸 경우, PK가 중복될 수 있기 때문에 식별자의 유일성이 보장되지 않는다!

여러 사드에서 동일한 PK를 가지는 상황

2. 클라이언트 측에 노출하면 보안 문제(데이터 개수 또는 특정 시점의 식별자 예측 가능)

     ex) 방금 가입했더니 user_id가 1000이라면 -> 1000명의 회원이 있음 유추 가능

 

장점

간단하므로 다음 상황에서 유리

• 보안적인 문제를 크게 고려하지 않는 상황
• 단일 DB를 사용하거나 애플리케이션에서 PK 중복을 직접 구분하는 상황

참고

보안적인 문제만 염려된다면 PK는 DB 내 식별자로 활용하고 앱 내 식별자를 위해 별도 유니크 인덱스 사용 가능

• PK = id(DB auto_increment)
• unique index = article_id(UUID 등)
• Client는 article_id만 식별자로서 노출 및 사용
• but Secendary index로 포인터(PK) 찾은 후, Clustered index 접근하므로 조회 비용 증가

---

유니크 문자열 or 숫자

UUID 또는 난수를 생성하여 PK 지정 (정렬 데이터가 아니라 랜덤 데이터를 삽입하는 것)

 

장점

키 생성 방식이 간단

 

문제점

랜덤 데이터로 인해 성능 저하

• Clustered Index는 정렬된 상태를 유지한다.
• 데이터 삽입 시 필요한 인덱스 페이지가 가득 찼다면, B+tree 재구성 및 페이지 분할로 디스크 I/O 증가
• PK를 이용한 범위 조회 시 디스크에서 랜덤 I/O가 발생하므로, 순차 I/O보다 성능 저하
  
  

정렬 가능한 ID는 클러스터형 인덱스(InnoDB의 경우 PK)의 물리적 저장 순서와 유사하게 생성되어 
페이지 분할 및 재구성을 줄여 쓰기 및 범위 쿼리의 디스크 I/O 효율을 높인다.

---

유니크 정렬 문자열

UUID v7, ULID 등의 알고리즘을 통해 생성 (보통 128 비트 사용)

 

장점

• 분산 환경에 대한 PK 중복 문제 해결
• 보안 문제 해결
• 랜덤 데이터에 의한 성능 문제 해결

 

문제점

데이터 크기에 따라, 공간 및 성능 효율이 달라진다.

• Clustered Index는 PK를 기준으로 만들어진다.
• Secondary Index는 데이터에 접근할 수 있는 포인터, 즉 PK를 가진다
• PK가 크면 클수록, 데이터는 더 많은 공간을 차지하고, 비교 연산에 의한 정렬/조회에 더 많은 비용을 소모한다.

---

유니크 정렬 숫자

장점

앞서 살펴본 문자열 방식의 장점을 모두 취하면서, 보다 적은 공간을 사용한다.

 

snowflake, TSID 등의 알고리즘은 64비트 사용(BIGINT)

• 정렬을 위해 타임스탬프를 나타내는 비트 수 제한으로, 문자열에 비해 키 생성을 위한 시간적인 한계가 있을 수 있음

---

결론

상황에 따라 다르겠지만, 분산 DB 환경에서는 유니크 정렬 숫자를 채택하는 것이 좋아보인다.

• PK가 분산 DB 환경에서 중복되지 않으면서,
• 클라이언트에 노출되어도 보안 문제가 없어야하며,
• 정렬된 값이라 인덱스 성능에도 좋고,
• 문자열보다 크기가 작다!

 

---

참고 자료 & 이미지 출처
스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 게시판