제목이 논리적으로 말이 안되어서 어그로 글인줄 알 수도 있겠지만, 직관적으로 무슨 내용의 글인지 바로 알 수 있는 짧은 제목을 찾다보니 저래됐다… 진짜 제목은 ‘primary key로써 순차증가하는 숫자키 vs UUID’.
새로운 서비스를 만들면서 데이터베이스의 primary key의 데이터 타입을 uuid로 할까 그냥 기본값으로 순차증가하는 정수로 할까 고민하면서 구글링 해봤다.
UUID의 장점
- 범용적으로 유니크함. 사실 정말 유니크하진 않다. 하지만 경우의 수가 어마어마해서 ‘유일함을 보장’한다고 함. 순차증가키를 사용하면 id=1인 데이터는 전세계에 무수히 많지만, uuid키를 사용하면 해당 id를 가진 데이터는 유일무이하다.
- 외부에서 다른 리소스에 임의로 접근을 시도할 확률이 낮아짐. 순차증가 키는 이전 리소스와 다음 리소스의 id를 추측할 수 있지만, uuid는 불가능하다.
- Client side에서 id를 생성 가능. 순차증가 키는 데이터베이스를 거치지 않으면 다음에 생성될 데이터의 id를 알 수 없지만, uuid는 그냥 생성해서 삽입하면 된다.
UUID의 단점
- 속도. DBMS에 따라 다르지만 순차증가 키에 비해 인덱싱 속도가 느리다.
- 용량. 8byte인 big integer보다 2배 크다. 외부 키까지 고려하면 이 차이는 무시못할 수준.
내부에선 순차증가 키를 사용하고 외부와는 uuid를 사용하는 방법도 있었는데, uuid의 단점을 커버하기 위해 장점을 다 포기하는 꼴이라 좋은 전략이라고 볼 수 없다.
결국 UUID를 사용하기로 결정했다. 통신없이 id 생성이 가능한 점이 마이크로 서비스에서 유리하다고 판단했고, 테이블의 병합과 분리가 간단해서 확장성이 높다고 봤다. 또 테이블을 조인하는 쿼리를 실행할 때 사람이 실수할 확률을 낮춰줄 수 있지 않을까 하는 기대도 있다.
데이터가 적은 서비스 초기에 퍼포먼스 이슈는 무시해도 될 것 같고, 데이터가 많아지면 유연한 확장성으로 퍼포먼스 이슈를 해결할 수 있으리라 생각한다.