PK: UUID vs Auto Increment

UUID

UUID는 범용 고유 식별자이다.

물론 무조건 유일을 보장하지는 않지만, UUID는 범위가 10의 38승이기 때문에 실질적으로 거의 유일하다고 볼 수 있다.

 

장점

1. 분산 시스템에서 적절하다. (auto increment에서 설명)
2. DB 환경에 독립적이다. (어떤 DB를 사용하든 uuid 생성 함수를 사용하면 된다)

 

단점

1. 성능에 저하를 일으킨다 → 검색의 효율을 위해 id를 정렬한다면? UUID는 엄청 큰 문자열이기 때문에 정렬하는 비용이 생각보다 많이 든다.
2. 사람이 보기 힘들다.

 

Auto Increment

1부터 시작해서 데이터가 추가될 때마다 자동으로 숫자를 늘려가는 방식이다.

+) 물론 타입을 조심해야 한다. 데이터가 21억 건이 넘어가면? → Integer로는 부족하다.

 

장점

1. 빠르다. 눈에 보기 쉽다.
2. 특히 로그를 볼 때 편하다.

 

단점

1. 분산 시스템에 적절하지 않다

→ 서로 다른 환경에 있는 DB의 경우? 각 DB에 맞게 auto increment가 되어 있는건데, 이는 한 쪽에 있는 ID가 다른 쪽에도 존재할 수 있 다는 뜻이다.

→ 즉, duplicate key가 발생하여 PK라는 특성에 적합하지 않으며, 두 DB를 통합이라도 하게 되는 경우 골치아파질 수 있다.

 

실무

상황에 따라 UUID, auto increment를 사용하면 되겠지만, 꼭 이 둘에 국한될 필요는 없을 것 같다.

만약 계좌번호와 같이 자연키이지만 유일와 불변이 보장되는 데이터라면 PK로 설정해도 된다.

내 생각엔 시스템 규모가 커질수록 분산 시스템을 사용하고 이에 따라 UUID와 같은 명확한 PK를 설정할 것 같은데,

이러면 알아보기 복잡한 UUID보다 명확하고 비즈니스 로직에서도 사용할 수 있는 자연키를 PK로 두는 것도 하나의 방법이라고 생각한다.

 

+) 논외로 UUID가 엄청난 범위를 자랑하지만, 지금 근무하는 회사에서 UUID 중복으로 문제가 생긴 적이 꽤 있다고 한다..! 이게 가능한가 싶지만 가능한 가 보다.

 

참고자료

 

https://velog.io/@qnfmtm666/DevTip-UUID-vs-Auto-Increment

https://wjdtn7823.tistory.com/59

https://multifrontgarden.tistory.com/180