[Primary Key 생성 전략] #5. 유니크 정렬 문자열 (정렬 가능한 랜덤 ID)

 

 

---

 

# 0. 들어가며

 

UUID는 유니크한 값을 생성하는 데 탁월하지만, 랜덤성이 너무 강해서 데이터베이스 성능에 악영향을 줄 수 있습니다. 이를 보완하기 위해 등장한 것이 유니크 정렬 문자열(정렬 가능한 랜덤 ID) 방식입니다. 

 

 

---

 

# 1. 일반적인 UUID보다 나은 이유

 

UUID(특히 UUIDv4)는 완전한 랜덤 값이라서 저번 글에서도 다뤘지만 다음과 같은 문제점이 있습니다. 

 

1. 정렬이 불가능해서 인덱스 성능 저하

• UUID는 무작위 값이므로 새로운 데이터가 들어올 때마다 기존 데이터 사이에 삽입됩니다.
• 결과적으로 인덱스가 자주 조각화(Fragementation)되어 성능 저하 발생합니다.
• 반면, 정렬된 ID를 사용하면 B+트리 인덱스에서 삽입/검색 속도가 향상됩니다

 

2. 가독성이 나쁨

• UUID(550e8400-e29b-41d4-a716-446655440000)는 너무 길고 복잡해서 사람이 읽고 다루기 불편합니다
• 로그 분석이나 디버깅할 때도 UUID가 너무 길어 가독성이 떨어집니다

 

3. 저장 공간 증가

• UUID는 128비트(16바이트) 크기
• 일반적인 숫자형 ID(BIGINT, 64비트, 8바이트)보다 2배 크므로 DB 용량을 더 차지합니다.

 

 

✔   유니크 정렬 문자열(정렬 가능한 랜덤 ID)이란?

UUID의 유일성을 유지하면서도, 데이터가 정렬될 수 있도록 설계된 식별자입니다. ID가 생성될 때 시간 정보가 포함되므로, 정렬이 가능합니다. 또한 랜덤성은 그대로 유지하기에 충돌 없이 유니크함을 보장하며 UUID보다 짧고 직관적인 ID를 통해 가독성을 개선한 방식입니다.

 

 

 

---

 

# 2. 예제 및 실제 사용 사례

 

📌 예제 1: ULID (Universally Unique Lexicographically Sortable Identifier)

 

01F8MECHZX3TBXYN9YWK5GEC74

 

• 앞부분(10자리): 타임스탬프 (밀리초 단위)
• 뒷부분(16자리): 랜덤 값

 

ULID 활용 사례

• 대규모 로그 시스템 (시간 순서대로 정렬 가능)
• 데이터베이스에서 성능 최적화된 키 생성

 

 

 

 

📌 예제 2: KSUID (K-Sortable Unique Identifier)  

KSUID는 Twitter의 Snowflake처럼, 유니크하면서도 정렬 가능한 식별자입니다.

 

0ujss54H3k6PyrQEYFjP8sKZ0MT

 

• 앞부분(4바이트): UNIX 타임스탬프 (초 단위)
• 뒷부분(16바이트): 랜덤 값

 

 

KSUID 활용 사례

• 대규모 분산 시스템에서 정렬 가능한 ID 필요할 때
• 소셜 네트워크 서비스에서 유저, 게시글 ID로 활용

 

 

---

 

# 3. 장점과 단점

 

장점 

✔ 정렬 가능 → 인덱스 성능 향상

• 시간 기반 정렬이 가능하여 DB 성능 저하를 방지합니다
• B+트리 인덱스에서 삽입/검색 속도가 빨라집니다

 

✔ 충돌 없이 유니크 보장

• 랜덤성을 포함하므로 분산 시스템에서도 중복 없이 사용 가능합니다

 

✔ 가독성 향상

• UUID보다 짧고, 사람이 읽을 수 있는 형태입니다

 

✔ 저장 공간 절약 가능

• UUID(128비트)보다 짧은 길이로 동일한 기능 제공합니다

 

 

단점

✔   UUID보다 약간 크기가 커질 수도 있습니다

• KSUID는 20바이트로 UUID(16바이트)보다 조금 더 큽니다

 

✔   일부 DB에서 기본 지원하지 않습니다

• MySQL, PostgreSQL 등에서는 별도의 라이브러리를 사용해야 합니다

 

✔  기존 UUID 기반 시스템과의 호환성 문제

• UUID를 이미 사용하고 있다면, KSUID/ULID로 변경하는 작업이 필요할 수 있습니

 

 

 

---

 

# 4. 해결 방법

 

✅ 해결 방법 1: ULID 사용 

 

ULID는 UUID보다 짧고 가독성이 좋아서 DB 인덱스 성능 향상 가능하며 충돌 없이 사용 가능합니다

 

CREATE TABLE users (
    id CHAR(26) PRIMARY KEY,  -- ULID 저장
    name VARCHAR(255)
);

 

 

✅ 해결 방법 2: KSUID 사용

 

 

KSUID는 Twitter의 Snowflake와 비슷한 기능을 제공하며, 정렬 가능한 ID를 생성합니다. KSUID를 사용하면 소셜 미디어 게시물, 트랜잭션 로그 등에 최적화된 ID 제공 가능합니다.

 

CREATE TABLE posts (
    id CHAR(27) PRIMARY KEY,  -- KSUID 저장
    content TEXT
);

 

 

 

---

 

# 5. 결론 

 

✅ UUID보다 성능이 중요할 때 (정렬 가능한 ID 필요) 사용하기 좋습니다.
✅ 로그 시스템, 소셜 미디어 게시물, 트랜잭션 ID 등에 사용하기 좋습니다. 
✅ 대규모 분산 환경에서 충돌 없이 ID를 생성해야 할 때 사용하기 좋습니다.

 

 

 

 

 

🔹 KSUID 공식 문서 (Segment 개발)
📌 https://github.com/segmentio/ksuid

🔹 ULID 공식 문서 (Universally Unique Lexicographically Sortable Identifier)
📌 https://github.com/ulid/spec

🔹 ULID vs UUID 성능 비교 블로그 (Citus Data)
📌 https://www.citusdata.com/blog/2017/03/09/comparison-of-unique-identifiers/