UUID 대신 8바이트 ID? URL을 예쁘게 만들려는 개발자의 도전!
개발자는 URL 길이 단축을 위해 UUID를 대체하는 8바이트 ID 스키마인 'smolid'를 Go로 구현함
'smolid'는 시간 기반 정렬(Temporal Ordering), 타입 식별자 임베딩(Type Identifier Embedding), 그리고 PostgreSQL bigint 지원을 특징으로 함
UUIDv7과의 성능 비교를 통해 고유성 확보를 위한 트레이드오프(Trade-off)를 제시하며, 100만 건/초 생성 시 99.1%의 충돌 확률을 보임
ID 추적(ID Tracking)의 어려움과 분산 시스템(Distributed System)에서의 ID 관리 방안에 대한 커뮤니티 논의가 진행됨
smolid의 기술적 특징
개발자는 URL 친화적인 ID를 목표로, 8바이트 크기의 'smolid'를 설계했다. 이 ID는 41비트의 밀리초 단위 타임스탬프(Millisecond-Precision Timestamp), 버전 정보, 타입 식별자, 그리고 랜덤 데이터를 포함한다. 특히, PostgreSQL bigint 타입과의 호환성을 고려하여 데이터베이스 인덱스 효율을 높이려 했다. 또한, 128개의 타입 식별자를 ID에 임베딩하여 ID만으로도 객체의 타입을 파악할 수 있도록 설계했다.
UUIDv7과의 성능 비교 및 트레이드오프
게시물에서는 'smolid'와 UUIDv7의 고유성(Uniqueness)을 비교하며, 트레이드오프를 명확히 제시한다. UUIDv7은 74비트의 엔트로피(Entropy)를 제공하여 100만 건/초 생성 시 0.000000000000002%의 충돌 확률을 보이지만, 'smolid'는 20비트의 엔트로피로 인해 99.1%의 충돌 확률을 보인다. 이는 URL 길이 단축이라는 목표를 달성하기 위해 고유성을 희생한 결과이다.
ID 관리의 어려움과 추적 시스템 구축
커뮤니티에서는 여러 서비스에서 생성된 UUID를 추적하는 어려움에 대한 공감대가 형성되었다. 한 사용자는 클라우드와치(CloudWatch)를 사용하여 ID를 검색하는 스크립트를 작성했다고 언급했다. 또한, 분산 시스템(Distributed System) 환경에서 중앙 집중식 추적 ID(Centralized Trace ID)를 사용하고, 모든 서비스에서 컨텍스트를 전파하는 것이 일반적인 방법이라고 강조했다. 이는 ID 관리의 중요성을 시사한다.
PostgreSQL에서의 부호 없는 정수 문제
저자는 'smolid'를 PostgreSQL bigint에 저장할 때 발생할 수 있는 문제점을 지적한다. ISO/IEC SQL 표준은 부호 없는 정수를 정의하지 않으며, PostgreSQL 또한 이를 지원하지 않는다. 따라서, 2059년에는 가장 상위 비트가 뒤집히는 문제가 발생하여 데이터베이스 인덱스(Database Index)의 효율성이 저하될 수 있다. 이는 향후 PostgreSQL 프로젝트 또는 ISO/IEC에서 해결해야 할 과제이다.
