개발자 도구 · UUID 생성기
ULID, Snowflake, KSUID 및 UUIDv7: 정렬 가능한 ID 비교
· 배경
uuid 암호화 브라우저 API
무작위 UUID는 생성 시간을 기준으로 정렬되지 않으므로 여러 형식에서 타임스탬프를 먼저 배치합니다. 이 게시물에서는 ULID, Snowflake, KSUID 및 UUIDv7의 레이아웃, 크기, 단조로움 및 호환성을 비교합니다.
무작위 ID와 이를 싫어하는 인덱스 — 시간순으로 정렬된 식별자가 해결하는 문제
무작위 v4 UUID는 새 레코드가 도착할 때 B-트리 기본 키 전체에 삽입 지점을 분산시켜 페이지 분할 및 재구성을 유발합니다. 임의 위치에 삽입하면 쓰기 성능이 저하되고 디스크 조각화가 크게 늘어납니다. 처리량이 높은 데이터베이스는 진정으로 독립적이고 조정되지 않은 식별자의 가격인 이 비용을 허용하지만 그 비용은 현실입니다. 생성 시간을 기준으로 정렬하기 위해 UUID가 필요한 경우 타임스탬프 접두사를 추가하여 인덱스 특성을 크게 향상시킬 수 있습니다. ULID, Snowflake, KSUID 및 RFC 9562 v7 등 여러 형식이 등장했습니다. 각각은 크기(26자에서 128비트까지), 타임스탬프 정밀도(초에서 나노초까지), UUID 호환성, ID 생성기 조정에 중앙 집중화가 필요한지 여부 등에서 서로 다른 장단점을 갖습니다. 데이터베이스 벤치마크에서는 삽입 성능이 크게 향상되는 것으로 나타났습니다.
ULID — 48비트 밀리초 타임스탬프와 26 Crockford base32 문자의 80 임의 비트(단조 옵션 포함)
ULID(Universally Unique Lexicographically Sortable Identifier)는 Crockford base32의 26 문자로 48비트 밀리초 타임스탬프와 80비트 무작위 페이로드를 인코딩합니다. 텍스트 표현은 사전순으로 올바르게 정렬되므로 ULID는 타임스탬프 순서 및 가독성이 중요한 시스템(로그 처리, 분산 추적, 사람이 보는 출력에서 식별자를 쉽게 읽을 수 있어야 하는 마이크로서비스)에 적합합니다. ULID는 동일한 밀리초 내에 생성된 여러 식별자가 반복하는 대신 무작위 부분을 증가시키는 단조로운 변형을 제공하여 빠른 ID 버스트라도 엄격한 생성 순서를 유지하도록 보장합니다. 단점은 ULID가 UUID이 아니라는 점입니다. 인코딩 변환 없이는 표준 128비트 UUID 데이터베이스 열에 맞지 않습니다. ULID 정밀도는 약 8925년 동안 적용됩니다.
Snowflake — 타임스탬프의 64비트 ID, 작업자 ID, 시퀀스 및 필요한 조정
Snowflake는 원래 Twitter에서 설계한 64비트 식별자로, 41비트 밀리초 타임스탬프, 10비트 작업자 ID 및 12비트 시퀀스 번호로 구성됩니다. 41비트 타임스탬프는 약 69년을 다루며 2106에서 오버플로되므로 시대 조정 및 마이그레이션 계획이 필요합니다. 작업자 ID는 다양한 서버 또는 프로세스에서 생성된 식별자를 구별합니다. 각 Snowflake 생성기는 다른 생성기와 충돌하지 않고 고유한 작업자 ID를 알아야 합니다. Snowflake는 128 대신 64 비트이므로 UUID 크기의 절반이고 색인 생성 속도가 빠르며 식별자당 저장 효율성이 더 높습니다. 시간과 작업자 ID를 기준으로 정렬하므로 소스별로 요청이나 로그를 라우팅하는 데 유용합니다. 단점은 운영상의 문제입니다. 모든 발전기에는 작업자 ID가 할당되어야 하고 시계는 동기화된 상태로 유지되어야 합니다.
KSUID — 대용량 무작위 페이로드가 포함된 초 타임스탬프(바이트로 정렬)
KSUID(K-정렬 고유 식별자)는 32비트 Unix 두 번째 타임스탬프와 96비트 무작위 페이로드로 구성된 128비트 식별자이며 일반적으로 27 base62 문자로 인코딩됩니다. 형식은 사전식 순서로 정렬 가능하며 임의의 부분은 크기에 비해 암호학적으로 건전합니다. KSUID는 ULID 또는 Snowflake보다 널리 채택되지는 않지만 고유한 의미를 제공합니다. 타임스탬프는 사람이 읽을 수 있는 초로 쉽게 디코딩되며(로그 및 디버깅에 유용함) 96비트 무작위 부분은 동일한 초에 생성된 여러 KSUID가 시퀀스 조정 없이 중복 확률이 사실상 0이 될 만큼 충분히 큽니다. Snowflake와 달리 KSUID에는 작업자 ID 조정이나 중앙 할당이 필요하지 않습니다. KSUID는 밀리초가 아닌 초 단위로 작동하므로 추가 논리를 구현하지 않는 한 1초 내에 여러 ID가 무작위로 정렬됩니다.
UUIDv7 — 기존 uuid 열 및 도구에 맞는 표준 추적 답변
RFC 9562 v7은 48비트 Unix 밀리초 타임스탬프, 12비트(시퀀스 카운터로 사용 가능) 및 62 임의 비트가 모두 결합된 128비트 식별자입니다. 사전식 문자열과 데이터베이스의 128비트 바이트로 올바르게 정렬됩니다. 결정적으로 이는 유효한 UUID입니다. 버전 니블을 7로 설정하고 변형 비트를 RFC 9562 표준으로 설정하여 UUID를 처리하는 모든 도구, 데이터베이스 열 및 API와 호환되도록 합니다. 인코딩 변환이 필요하지 않으며 기존 UUID 인프라를 수정할 필요가 없습니다. 동일한 밀리초에 여러 v7 식별자가 생성되는 경우 RFC 9562에서는 밀리초 미만 필드를 무작위 비트가 아닌 단조 카운터로 사용할 것을 권장합니다. V7은 UUID 호환성을 유지하기 위한 실용적인 선택을 나타냅니다.
1밀리초 이내의 단조성 — 각 형식이 버스트를 처리하는 방법 및 주문 보장에 중요한 이유
단조성은 두 이벤트가 관찰 가능한 순서로 발생하는 경우 해당 ID가 동일한 순서로 비교되는 속성입니다. 최신 하드웨어의 밀리초 수준 세분성에서는 동일한 시계 틱 내에서 여러 이벤트가 일상적으로 발생하므로 모든 정렬 가능한 ID 체계는 밀리초 미만 순서를 올바르게 처리해야 합니다. ULID는 무작위화 대신 무작위 부분이 증가하는 명시적 단조 모드를 제공합니다. Snowflake에는 밀리초 틱 내에서 증가하는 12비트 시퀀스 번호가 포함되어 있습니다. KSUID에는 기본 제공 메커니즘이 없으므로 추가 논리가 추가되지 않는 한 1초 미만의 이벤트가 무작위로 정렬됩니다. RFC 9562 v7에서는 밀리초 미만 필드를 단조 카운터로 사용할 것을 권장합니다. 시스템이 초당 수천 개의 UUID를 생성하는 경우 밀리초 내의 단조성은 쿼리 순서에 큰 영향을 미칩니다.
여기서 다루지 않는 내용 — 하드웨어 및 언어에 따라 달라지는 처리량 벤치마크입니다. 게시물의 품질이 유지됩니다
처리량 벤치마크 및 성능 데이터는 하드웨어 아키텍처, 언어 구현, 데이터베이스 엔진 및 캐싱 전략에 크게 의존하기 때문에 포함되지 않습니다. 데이터베이스 성능 특성은 임의 삽입, 범위 쿼리, 인덱스 오버헤드 또는 실제 프로덕션 로드 하에서 총 처리량을 측정하는지 여부에 따라 크게 달라집니다. 게시물은 오해의 소지가 있는 환경별 수치를 제공하기보다는 디자인을 기반으로 개념적으로 형식을 비교하여 질적으로 유지됩니다. 실제 성능 평가에는 자체 워크로드, 코드베이스 및 운영 제약 조건이 있는 자체 환경에서 테스트가 필요합니다. 다양한 ID 형식을 벤치마킹하는 것은 귀중한 활동입니다.
요점: 호환성이 종종 결정됩니다. ToolAcre 생성기는 임의의 UUID를 생성합니다. 올바른 형식의 검사를 사용하여 라이브러리의 UUIDv7이 UUID로 구문 분석되는지 확인하세요.
호환성에 따라 선택할 형식이 결정되는 경우가 많습니다. 데이터베이스 스키마에 이미 UUID 열이 필요한 경우 v7은 UUID 생태계를 벗어나지 않고도 정렬 가능성에 대한 현대적인 대답입니다. 사용자 정의 ID 유형으로 새 시스템을 구축하는 경우 ULID는 더 작은 텍스트 표현과 밀리초 정밀도 이점을 제공합니다. 64비트 스토리지가 필요하고 중앙 집중식 할당을 통해 작업자 ID 조정을 관리할 수 있는 경우 Snowflake는 대용량 시스템에서 입증된 선택입니다. 근본적인 절충점은 표준 호환성(v7 선택)과 더 작은 크기(Snowflake) 또는 base32 가독성(ULID)과 같은 대체 속성 사이에 있습니다. 시스템 제약과 생태계 결정을 기반으로 선택하세요.