[DB] UUID를 고유 값이나 Key로 사용하면 안되는 이유

1. UUID를 고유 값으로 쓰면 안되는 이유

1. RDB 기준 사용시 성능 이슈 + 충돌 가능성이 있기 때문이다. (https://velog.io/@injoon2019/UUID-vs-ULID)
   • 인덱스는 기본적으로 B-tree 인덱스를 사용하는데, 무작위 렌덤의 uuid를 사용하면 sort를 사용할 수 없다.
   • int, bigint를 사용하는 것에 비해 uuid를 pk로 사용하면 상대적으로 성능이 낮다.
   • uuid 단독으로 사용하면 생성시 충돌 가능성이 있다. 
   • 128비트의 공간을 지속적으로 차지하는 단점
   • (uuid를 사용하면 DB 마이그레이션이 편한 이점 있음)

2. 해결책

1. [결제 고유 번호 uuid + 날짜_회원정보] 이런식으로 저장해야한다. (스노플레이크 접근이라고 한다. https://thalals.tistory.com/440)
2. UUID 생성 라이브러리 사용하기 (AWS에서 sorting key로 추천 - https://www.youtube.com/watch?v=I7zcRxHbo98&t=2s)
   1. KSUID (https://www.npmjs.com/package/ns-ksuid)
      
      • sorting 가능한 uuid
      • 예전에 dynamodb 붙이려고 공부할때 알게 된 라이브러리
        • GO로 만들어졌으며, 생성시간에 따라 정렬되고, 충돌 없음 보장 (https://github.com/segmentio/ksuid)
   2. ULID (https://github.com/ulid/javascript)
      1. ULID는 생성 순서를 밀리세컨 단위로 기록할 수 있어서, 생성 순서대로 정렬, 충돌 가능성 x

3. Reference

 

- RDB pk uuid 베스트 프렉티스 :  https://vladmihalcea.com/uuid-database-primary-key/

The best UUID type for a database Primary Key - Vlad Mihalcea

 

- https://velog.io/@devkingsejong/RDB에서-UUID를-무작정-사용하지-말아야-하는-이유

RDB에서 UUID를 사용할 때 고민해볼점