UUID v4 기본키를 피해야하는 이유

UUID v4의 성능 문제

UUID v4는 122비트가 무작위로 생성되어 인덱스 정렬이 불가능하고, 순서성이 없어 삽입 효율이 낮음

각 삽입이 임의의 페이지에 기록되어 중간 페이지 분할이 자주 발생

이로인해 쓰기 지연과 WAL 증가가 발생함

 

 

 

UUID의 구조와 대안

UUID는 128비트(16바이트) 크기의 식별자이며, PostgresSQL에서는 binary uuid 타입으로 저장됨

UUID v4는 무작위 비트 기반, UUID v7은 앞 48비트에 타임스탬프를 포함해 인덱스 효율이 높음

PostgresSQL 18에서 UUID v7을 지원 예정

UUID v7은 시간순 정렬이 가능해 페이지 밀도와 캐시 효율이 개선됨

 

 

 

UUID 선택 이유와 한계

다중 클라이언트나 마이크로서비스 환경에서 충돌 없는 식별자 생성이 필요 할 때 UUID가 사용됨

그러나 RFC 4122는 "UUID는 추측이 어렵다고 가정하지 말라"고 명시

보안 식별자로 부적합

 

 

 

UUID의 공간 및 I/O 비효율

UUID는 bigint(8바이트)의 두 배, int (4바이트)의 네 배 공간을 차지

대규모 테이블에서는 저장 공간 증거와 백업, 복원 시간 증가로 이어짐

 

- 인덱스 페이지 밀도 실험 결과

integer 인덱스 = 97.64%

UUID v4 인덱스: 79.06%

UUID v7 인덱스 : 90.09%

 

 

 

캐시 및 메모리 영향

UUID는 랜덤 분포로 인해 버퍼 캐시 적중률 (cache hit ratio)이 낮음

캐시 효율 저하로 쿼리 지연이 발생하며, 메모리 사용량 증가

성능 유지를 위해 정기적인 인덱스 재구성 또는 pf_repack 사용 권장

 

 

 

성능 완화 방안

메모리 확장 (데이터베이스 크기의 4배 RAM 확보 권장)

work_mem 조정 (정렬 연산 시 더 많은 메모리 할당으로 성능 개선 가능)

 

 

 

정수형 키와 시퀀스 권장

신규 데이터베이스에는 정수형 시퀀스 기반 키 사용 권장

 

 

 

 

 

 

Reference

https://news.hada.io/topic?id=25109

Postgres에서 UUID 버전 4 기본 키를 피해야 하는 이유 | GeekNews