DB PK 전략 - UUID를 PK로..?

 

이제까지 프로젝트를 수행할 때 DB PK 전략을 AUTO_INCREMENT를 사용했었다. 

 

하지만, 이번에 주문 앱 개발 프로젝트를 하면서 DB PK의 전략에 대한 이야기가 나왔다. 

• 일반적으로 사용하는 AUTO_INCREMENT 전략에는 몇 가지 문제가 있다고 한다. 

 

따라서, 이 주제에 대해 팀원분들과 튜터님과 같이 나누었던 이야기 내용에 대해서 정리해보려고 한다. 

 

AUTO_INCREMENT 전략 문제점 

1. 다른 데이터들을 쉽게 추적할 수 있다. 
2. 분산 시스템에서 ID가 고유하지 않을 수 있다. 

위의 문제점이 발생한다고 한다. 

 

조금 더 자세히 알아보자. 

 

1. 다른 데이터들을 쉽게 추적할 수 있다. 

지금 쓰고 있는 티스토리 블로그만 봐도 알 수 있다. 

• URL의 가장 뒤에 ~~~/[숫자]
• 글을 쓰면 숫자들이 글을 쓴 수 만큼 차례대로 올라간다는 것을 알 수 있다.
• 숫자를 보고 글의 양을 추측 가능하다.  

어떻게 보면 불필요한 정보를 노출하는 것 일 수도 있다. 

 

데이터의 수를 나타내기 때문에 기업의 매출량과도 관련이 있을 수 있다. (튜터님과 이야기하면서 아하..! 라고 생각이 들었던 부분이다..)

 

2. 분산 시스템에서 ID가 고유하지 않을 수 있다.

프로젝트의 규모가 커지면 데이터의 수가 많아지므로, DB를 분산시킬 수도 있다. 

 

분산 DB의 환경에서 AUTO_INCREMENT 전략을 사용하면 각각의 DB 별로 1부터 시작해서 PK가 겹치는 문제가 발생할 수 있다.

 

따라서, 다른 DB에서 데이터를 모아야 할 때 PK가 중복되어서 PK의 고유함이 사라지게 된다. 

 

 

때문에, 실무에서는 보통 PK를 bigint 타입의 AUTO_INCREMENT로 두고, UUID 컬럼은 UNIQUE 값으로 둔다고 한다. 

• 데이터베이스가 bigint 타입의 PK로 데이터를 관리하도록 하고 외부에 노출시키는 것은 UUID로 한다. 

만약, 분산 DB 환경도 고려를 해본다면..

• 분산 DB의 환경에서는 AUTO_INCREMENT 보다는 UUID 전략을 사용하는 것이 좋지만, UUID도 완벽하지는 않다고 한다. 
• Snowflake 전략을 사용하는 것이 권장된다고 한다. 

 

우선, 어떤 전략을 사용하든 간에 PK는 외부로 노출시키지 않는 것이 좋다고 한다. 

 

뭐든지 Trade-Off는 항상 존재하는 것 같다.