[DB]

[DB] UUID를 Primary Key로 사용하기

danhan 2022. 7. 7. 11:50

UUID

UUID는 범용 고유 식별자로 네트워크 상에서 서로 다른 개체들을 구별하기 위해 만들어진 방법이다. 32개 문자, 4개의 하이픈으로 이루어져 있어 생성할 수 있는 값은340,282,366,920,938,463,463,374,607,431,768,211,456개이다. 고유성을 완벽하게 보장할 수는 없지만, 실제 사용할 때 중복될 가능성이 거의 없다

UUID는 생성 방법에 따라 5가지 vertion이 존재한다. TimeStamp 기반의 v1/v2, 완전 Random 기반의 v4, Hashing 기반의 v3/v5가 존재한다. 실제로는 v1/v4/v5가 주로 이용된다. Random한 UUID를 생성하기 위해서는 v1/v4를 이용하고, 고정된 UUID를 생성하기 위해서는 v5를 이용한다. PK를 생성할 때는 UUID v4를 사용하면 된다.

UUID를 Primary key로 사용하는 이유

여러 데이터베이스를 사용하거나 분산된 환경에서 애플리케이션을 운영할 경우에도 PK를 고유하게 생성할 수 있다. auto increment로 ID를 생성하면 서로 다른 테이블에서 같은 ID가 사용될 확률이 높다. 같은 ID가 사용되면 두 테이블을 합칠 때 때 ID가 충돌할 수 있다. UUID는 고유한 값이기에 충돌 문제없이 테이블을 자유롭게 합칠 수 있다.

UUID는 State less해서 함수를 사용해 어디서든 키를 생성할 수 있다. 어디서 키를 생성하든 고유값을 가지기에 PK가 반드시 DB에서 생성될 필요가 없다. 데이터를 insert할 때 increment pk를 구하는 쿼리를 요청하지 않아도 된다.

데이터에 대한 정보가 노출되지 않아 보안상 안전하다. 회원 정보를 increment pk로 저장한 경우 다른 회원의 정보를 쉽게 유추할 수 있다.

성능 저하

PK 값으로 주로 사용하는 Auto Increment는 INT형으로 MariaDB를 기준으로 8 bytes이다. UUID는 BINARY형으로 16 bytes이다. AI가 아닌 UUID로 PK를 생성할 때 스토리지가 2배 더 필요하다.

그리고 UUIDv4의 경우 unique 하지만 무작위 값이므로 indexing할 때 DB에 큰 부담이 된다. 테이블에 데이터가 많으면 DB의 성능이 저하될 수 있다.

해결 방법

무작위 생성으로 인한 성능 저하 이슈를 해결하는 방법은 UUID를 랜덤 생성하되 이를 sequential하게 생성하는 것이다. UUID가 차례로 증가하므로 새로운 데이터가 들어오더라도 indexing으로 인한 리소스가 이전보다 줄어든다.

MySQL에선 Sequencial UUID를 생성하는 function을 만들어 사용하면 된다.

생성 방법 참고 : https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/#crayon-60fa2fbab27f7557869434

프로젝트에서 PK를 UUID로 선택한 이유

프로젝트에선 개인정보보호 목적으로 사용자의 id값을 숨기기 위해 UUID를 사용하려고 한다.

UUID 사용시 성능 저하 이슈가 있을 수 있지만 프로젝트 규모가 작아 성능 저하의 정도가 작아 UUID를 사용했을 때의 단점보다 장점이 더 많다고 생각했다.

그리고 개인정보보호가 필요하지 않은 ID는 기존 방식대로 Auto increment로 만들 것이다.

참고