GN⁺: 스트라이프 ID에서 영감을 받은 타입 안전한, K-정렬 가능한, 전역적으로 고유한 식별자

• TypeIDs: UUIDv7를 기반으로 한 Stripe의 API에서 영감을 받은 타입 안전한 확장입니다.
• TypeIDs는 타입 접두사, 밑줄 구분자 및 26자리의 base32로 인코딩된 128비트 UUIDv7로 구성됩니다.
• TypeIDs는 타입 안전성, UUID와의 호환성, K-정렬 가능성 및 신중한 인코딩과 같은 이점을 제공합니다.
• TypeIDs는 다가오는 UUIDv7 표준과 호환되며, 좋은 지역성을 가진 데이터베이스의 주 키로 사용할 수 있습니다.
• TypeIDs는 Go와 SQL에서 구현되어 있으며, Python, Rust 및 TypeScript에서의 구현이 곧 제공될 예정입니다.
• 이 기사에서는 TypeIDs를 생성, 해독 및 인코딩하는 명령 줄 도구에 대해 언급합니다.
• 이 기사에서는 UUIDv7 및 xid, ulid, ksuid와 같은 UUIDv7 대체제와 관련된 작업도 언급합니다.

[neo]

Hacker News 의견

• 접두사 문자열을 잠그고 문서화하는 제안이 제시되었으며, 복합 유형에 대해 단일 구분자를 허용합니다.
• 식별자의 Go 구현은 테스트가 부족하며, 단위 테스트가 필요합니다.
• 다른 제안은 Go에서 Google의 UUID 구현과 일치하도록 하여 문자열 대신 구문 분석 함수와 내부 바이트 배열을 사용하는 것입니다.
• 식별자의 설계 결정은 트레이드오프 사이에서 좋은 균형을 이루고 있다는 칭찬을 받았습니다.
• 다른 댓글러는 고유 식별자 생성에 대한 자신의 접근 방식을 공유하며, 모음 없이 32진법을 사용하고 체크섬을 추가하는 방법을 사용합니다.
• 그들은 Crockford 인코딩을 비판하며, 더 효과적이고 간결한 인코딩으로 base 58을 제안합니다.
• Crockford의 base-32 시스템에 대한 링크가 공유되었으며, "우연한 음란성"으로 인해 문자 U가 제외되어 혼란스러움을 표시합니다.
• 댓글러는 ORM에서 "태그된 ID"의 사용을 공유하며, 복사 및 붙여넣기에 대한 구분 기호로 밑줄을 사용하지 않은 것을 후회합니다.
• 식별자 구현에서 세부 사항의 중요성이 강조됩니다.
• UUIDv7이 표준이 되고 라이브러리와 데이터베이스가 기본적으로 지원되기를 원하는 욕구가 언급되었습니다.
• 데이터베이스에 대한 UUIDv4의 장단점이 논의되었으며, 분산 데이터베이스 애플리케이션에서는 UUIDv4을 선호합니다.
• 전체 ID를 더블 클릭하여 선택할 수 있는 기능의 유용성이 강조됩니다.
• 더 큰 키 공간과 정렬 가능한 타임스탬프를 제공하는 대체 ID 생성기인 ksuid가 권장됩니다.
• ksuid는 대부분의 언어에서 라이브러리를 제공하는 최고의 범용 ID 생성기로 칭찬받으며, UUID v1-7은 낭비적이라고 여겨집니다.