Intro
기존에는 주로 자동 증가 숫자 타입을 PK로 쓰곤 했는데, 최근에는 분산시스템에서도 사용 가능한 UUID를 데이터베이스의 기본 키(Primary Key)로 사용하는 경우가 많아지고 있다. 이번 글에서는 UUID및 숫자 타입을 PK로 사용했을때의 장단점을 비교해보고 추가로 대안도 찾아보자
각 타입의 특징
Numeric ID
성능: 숫자 기반이므로 저장 공간이 적고, 데이터베이스 인덱싱 성능도 우수하다. 조회 성능에서 유리하다.
단순함: 자동 증가 숫자 방식은 직관적이고, 값을 예측할 수 있어서 관리하기 쉽다.
가벼움: Long 타입은 8바이트(64비트)로 UUID보다 작아, 대규모 데이터베이스에서 저장 공간을 절약할 수 있다.
UUID
고유성과 확장성: UUID는 분산 시스템에서 중앙 서버 없이도 고유 식별자를 생성할 수 있다. 특히 대규모 분산 환경에서도 충돌 위험이 거의 없어 시스템의 확장성에 유리하다.
보안: UUID는 값이 예측하기 어려워, 공격자가 추적하거나 무작위 접근을 시도하는 것을 방지하는 데 유리하다.
무거움: UUID는 16바이트(128비트) 크기로, 8바이트(64비트)의 Numeric ID보다 저장 공간을 더 차지한다.
UUID와 숫자 타입을 병행 사용하는 방식
UUID와 숫자 타입을 병행하는 방식은 각각의 장점을 취하는 절충안이다. UUID를 외부 식별자로 사용하고, 숫자 타입을 내부 PK로 사용하는 구조로 설계할 수 있다.
클라이언트가 데이터를 조회하거나 API 요청에 포함할 때는 UUID를 사용해 보안을 강화할 수 있다.
데이터베이스에서는 숫자 타입 PK로 테이블을 연결해 성능과 저장 공간을 최적화할 수 있다. 외래 키(Foreign Key)로 참조할 때 성능상 이점이 있다.
대안
분산 시스템 환경에서 고유성과 성능을 함께 잡기 위한 대안으로 ULID와 Snowflake 같은 고유 식별자를 고려할 수 있다.
ULID
ULID는 UUID의 대안으로, 생성 순서에 따른 정렬 가능성을 추가한 고유 식별자다. 타임스탬프와 랜덤 값을 조합하여, 시간이 순차적으로 흐르면서도 거의 고유한 값을 생성한다. ULID는 UUID와 비슷한 고유성을 제공하면서도 더 효율적인 데이터베이스 정렬과 인덱싱을 가능하게 한다.
Snowflake
Snowflake는 Twitter에서 개발한 고유 식별자 생성 방식으로, 각 노드가 독립적으로 고유한 식별자를 생성하도록 설계되었다. 시간 기반 정렬이 가능하여 데이터베이스 인덱싱 성능이 높고, 대규모 트래픽을 처리하는 분산 시스템에서 적합하다.
결론
| 정렬 | 저장 공간 | 보안 | |
|---|---|---|---|
| UUID | 제한적 | 큼 | 높음 |
| 숫자 타입 | 가능 | 작음 | 낮음 |
| UUID + 숫자 타입 병행 | 가능 | 큼 | 높음 |
| ULID | 가능 | 중간 | 높음 |
| Snowflake | 가능 | 중간 | 높음 |
숫자 타입 PK는 성능과 저장 공간에서 여전히 좋은 선택이며 단일 서버 환경에서 최적화된 효율을 제공한다.
하지만 UUID는 확장성과 보안성이 중요한 분산 시스템에서는 더 나은 선택지가 될 수 있다. 순서를 보장해야 한다면 ULID나 Snowflake와 같은 대안을 사용해 고유성과 성능의 균형을 맞출 수도 있다.
References
'Data' 카테고리의 다른 글
| DBeaver 사용해 ERD 추출 (1) | 2024.11.22 |
|---|