(번역) Universally unique identifier

원문 보기: https://dawoum.duckdns.org/wiki/Universally_unique_identifier

Original article: w:Universally unique identifier

Universally Unique Identifier (UUID)는 컴퓨터 시스템에서 대상을 고유하게 식별하기 위해 사용되는 128-비트 레이블입니다. Globally Unique Identifier (GUID)라는 용어도 주로 Microsoft 시스템에서 사용됩니다.

표준 방법에 따라 생성될 때, UUID는 실용적인 목적에 대해 고유합니다. 그것들의 고유성은 대부분의 다른 번호 매기기 시스템과 달리 중앙 등록 기관이나 그것들을 생성하는 당사자 사이의 조정에 의존하지 않습니다. UUID가 중복될 확률은 영은 아니지만, 일반적으로 무시할 수 있을 정도로 영에 가까운 것으로 여겨집니다.

따라서, 누구나 UUID를 생성하고 식별자가 이미 생성되었거나 생성될 다른 것을 식별하기 위해 생성된 식별자와 중복되지 않는다는 것을 거의 확실하게 확신하면서 무언가를 식별하기 위해 사용할 수 있습니다. 따라서 독립적인 당사자에 의한 UUID로 레이블-지정된 정보는 나중에 단일 데이터베이스로 결합하거나 같은 채널에서 전송할 수 있으며, 중복 가능성은 무시할 수 있습니다.

UUID 채택은 널리 퍼져 있으며, 많은 컴퓨팅 플랫폼에서 UUID 생성과 텍스트 표현 구문 분석을 위한 지원을 제공합니다.

Print UUID

컴퓨터에서 필수 부품인 저장 장치는 리눅스에서 포맷과 마운트의 과정을 거쳐서 사용할 수 있습니다.

예를 들어, 저장 장치를 새로 사거나, 기존 저장 장치를 새롭게 파티션을 나누고 포맷할 때, uuid가 새롭게 생성됩니다.

물론, 디바이스 이름으로 마운트를 할 수 있지만, 대체로 uuid로 디바이스를 정하는 것을 선호하는 것으로 보입니다.

어쨌든, 마운트를 위해 uuid를 읽을 필요가 있습니다.

blkid /dev/sda1

Installation

여기서 사용되는 blkid는 util-linux 패키지 안에 존재합니다:

sudo apt install util-linux

History

1980년대에, Apollo Computer는 원래 네트워크 컴퓨팅 시스템 (NCS)에서 UUID를 사용했습니다. 나중에, Open Software Foundation (OSF)은 분산 컴퓨팅 환경 (DCE)에 대해 UUID를 사용했습니다. DCE UUID의 설계는 부분적으로 NCS UUID를 기반으로 했으며, 그들의 설계는 차례로 Apollo Computer에 의해 설계된 운영 시스템, Domain/OS에서 널리 정의되고 사용되는 (64비트) 고유 식별자에서 영감을 받았습니다. 나중에, Microsoft Windows 플랫폼은 DCE 설계를 "Globally Unique IDentifiers" (GUID)로 채택했습니다.

RFC 4122는 UUID에 대한 URN 이름공간을 등록하고 같은 기술적 내용을 갖는 이전 사양을 요약했습니다. 2005년 7월 RFC 4122가 제안된 IETF 표준으로 게시되었을 때, ITU도 이전 표준과 RFC 4122의 초기 버전을 기반으로 UUID를 표준화했습니다. 2024년 5월 7일, RFC 9562가 게시되어, 3개의 새로운 "버전"이 도입되고 일부 모호성이 해소되었습니다.

Standards

UUID는 분산 컴퓨팅 환경 (DCE)의 일부로 Open Software Foundation (OSF)에 의해 표준화되었습니다.

UUID는 ISO/IEC 11578:1996 "정보 기술 - 개방형 시스템 상호 연결 - 원격 프로시저 호출 (RPC)"의 일부로 문서화되었고 최근에는 ITU-T Rec. X.667 | SO/IEC 9834-8:2014에 문서화되었습니다.

인터넷 엔지니어링 태스크 포스 (IETF)는 "Revise Universally Unique Identifier Definitions Working Group"의 Standards-Track RFC 9562를 RFC 4122에 대해 개정판으로 발행했습니다. RFC 4122는 기술적으로 ITU-T Rec. X.667 | ISO/IEC 9834-8과 동등하지만, 현재는 더 이상 사용되지 않습니다.

Format

UUID는 크기가 128비트이며, 여기에서 2~4비트는 형식의 변형을 나타내기 위해 사용됩니다. 오늘날 가장 일반적으로 사용되는 변형, OSF DCE는 버전에 대해 4비트를 추가로 정의합니다.

남아있는 비트의 사용은 선택된 변형/버전에 따라 결정됩니다.

Variants

변형(variant) 필드는 UUID의 형식을 나타냅니다 (그리고 레거시 UUID의 경우에서 노드 필드에 대해 사용된 주소 가족도 나타냅니다). 다음 변형이 정의됩니다:

Apollo NCS 변형 (1비트 패턴 0xxx2로 표시)은 1988년경에 개발된 현재는 폐기된 Apollo Network Computing System 1.5 UUID 형식과의 하위 호환성을 위한 것입니다. 세부 사항은 다르지만, 최신 UUIDv1과의 유사성은 분명합니다. 현재 UUID 사양에서 변형 비트는 NCS UUID의 주소 가족 옥텟의 상위 비트와 일치합니다. 주소 가족은 0..255 범위에서 값을 보유할 수 있지만, 0..13 값만 정의되었습니다. 그에 따라, 비트 패턴 0xxx는 데이터베이스에 여전히 존재하는 역사적인 NCS UUID와의 충돌을 방지합니다. 이 변형은 "가족"을 하위-유형으로 정의합니다.
OSF DCE 변형 (10xx2)은 원래 인터넷 초안 작성자의 이름을 따서 RFC 4122/DCE 1.1 UUID, 또는 "Leach–Salz" UUID라고 참조됩니다. 이 변형은 "버전"을 하위-유형으로 정의합니다.
Microsoft COM/DCOM 변형 (110x2)은 RFC에서 "예약됨, Microsoft Corporation 이전 버전과의 호환성"으로 설명되고 Microsoft Windows 플랫폼의 초기 GUID에 대해 사용되었습니다.
예약된 변형 공간은 현재 어떤 사양에서도 사용되지 않습니다.

Versions of the OSF DCE variant

OSF DCE 변형은 표준에서 8개의 "버전"을 정의하고, 각 버전은 특정 사용 사례에서 다른 버전보다 더 적합할 수 있습니다. 버전은 UUID의 7번째 바이트의 상위 니블 (상위 4비트, 또는 상위 16진수 자릿수)의 값에 의해 표시됩니다. 16진수에서, 이는 두 번째 대시 뒤의 문자입니다. 예를 들어, UUID 9c5b94b1-35ad-49bb-b118-8e8fc24abf80은 두 번째 대시 뒤의 자릿자가 ...-49bb-...에서 4이기 때문에 버전 4입니다.

Versions 1 and 6 (date-time and MAC address)

버전 1은 "노드" (즉, UUID를 생성하는 컴퓨터)의 48-비트 MAC 주소를 60비트 타임스탬프와 연결하며, 타임스탬프는 협정 세계시 (Coordinated Universal Time, 줄여서 UTC) 1582년 10월 15일 자정 이후 100나노초 간격의 수이며, 협정 세계시 (UTC)는 대부분의 유럽에서 그레고리력이 처음 채택된 날짜입니다. RFC 4122는 시간 값이 사용된 알고리즘에 따라 서기 3400년경에 롤오버된다고 명시했으며, 이는 60-비트 타임스탬프는 부호화된 양임을 의미합니다. 어쨌든 libuuid 라이브러리와 같은 일부 소프트웨어는 타임스탬프를 부호-없는 것으로 처리하여, 롤오버 시간을 서기 5623년으로 설정합니다. ITU-T Rec. X.667에 의해 정의된 롤오버 시간은 서기 3603년입니다.

13-비트 또는 14-비트 "고유화" 클록 시퀀스는 프로세서 클록이 충분히 빨리 진행되지 않거나, 노드당 여러 프로세서와 UUID 생성기가 있는 경우를 처리하기 위해 타임스탬프를 확장합니다. UUID가 시스템 클록이 진행할 수 있는 것보다 더 빨리 생성될 때, 타임스탬프 필드의 하위 비트는 UUID가 생성될 때마다 증가시켜 생성하여 고해상도 타임스탬프를 시뮬레이션할 수 있습니다. 각 버전 1 UUID가 공간 (노드)과 시간 (간격 및 클록 시퀀스)의 단일 지점에 해당하므로, 적절하게 생성된 두 개의 버전 1 UUID가 의도치 않게 같을 가능성은 사실상 0입니다. 시간과 클록 시퀀스가 총 74비트이므로, 노드 ID당 \(2^{74}\)개(\(1.8\times 10^{22}\), 또는 1800조)의 버전-1 UUID를 생성할 수 있으며, 노드 ID당 초당 최대 평균률은 1630억입니다.

다른 UUID 버전과 달리, 네트워크 카드로부터 MAC 주소에 기반한 버전-1 및 버전-2 UUID는 고유성을 위해 중앙 등록 기관에서 발급한 식별자, 즉 IEEE에 의해 네트워크 장비 제조업체에 발급한 MAC 주소의 Organizationally Unique Identifier (OUI) 부분에 부분적으로 의존합니다. 네트워크-카드 MAC 주소에 기반한 버전-1 및 버전-2 UUID의 고유성은 네트워크-카드 제조업체가 카드에 고유한 MAC 주소를 적절히 할당하는 데 달려 있으며, 이는 다른 제조 공정과 마찬가지로 오류가 발생할 수 있습니다. 가상 기계는 하이퍼바이저에서 구성할 수 있는 범위에서 MAC 주소를 수신합니다. 추가적으로 일부 운영 시스템, 특히 OpenWRT에서는 최종 사용자가 MAC 주소를 사용자 정의할 수 있도록 허용합니다.

노드 ID에 대해 노드의 네트워크 카드 MAC 주소의 사용은 버전-1 UUID가 그것을 만든 컴퓨터로 추적될 수 있음을 의미합니다. 문서는 때때로 워드 프로세싱 소프트웨어에 의해 그것들을 삽입된 UUID를 통해 문서를 만들었거나 편집한 컴퓨터로 추적될 수 있습니다. 이 개인 정보 보호 홀은 Melissa 바이러스의 제작자를 찾는 데 사용되었습니다.

RFC 9562는 노드에 MAC 주소가 없거나 이를 노출하는 것이 바람직하지 않기 때문에 버전-1 (또는 2) UUID의 MAC 주소를 임의의 48-비트 노드 ID로 바꿀 수 있도록 허용합니다. 이 경우에서, RFC는 노드 ID의 첫 번째 옥텟의 최하위 비트를 1로 설정해야 한다고 요구합니다. 이는 MAC 주소에서 멀티캐스트 비트에 해당하고, 이를 설정하면 네트워크 카드 (전형적으로 유니캐스트 MAC 주소가 있음)에서 MAC 주소를 기반으로 하는 UUID에서 노드 ID가 무작위로 생성되는 UUID를 구별하는 데 도움이 됩니다.

버전 6은 모든 타임스탬프 비트가 가장 중요한 것부터 가장 중요하지 않은 것까지 정렬된다는 점을 제외하면 버전 1과 같습니다. 이를 통해 시스템은 어휘적으로 정렬함으로써 UUID를 생성 순서대로 정렬할 수 있지만, 버전 1에서는 불가능합니다.

Version 2 (date-time and MAC address, DCE security version)

RFC 9562는 "DCE 보안" UUID에 대해 버전 2를 예약합니다; 그러나 세부 정보는 제공하지 않습니다. 이러한 이유로, 많은 UUID 구현에서 버전 2를 생략합니다. 어쨌든, 버전 2 UUID의 사양은 DCE 1.1 인증 및 보안 서비스 사양에서 제공됩니다.

버전-2 UUID는 버전 1과 유사하지만, 클록 시퀀스의 최하위 8비트가 "지역 도메인" 번호로 대체되고, 타임스탬프의 최하위 32비트가 지정된 지역 도메인 내에서 의미 있는 정수 식별자로 대체됩니다. POSIX 시스템에서, 지역-도메인 번호 0과 1은 각각 사용자 id (UID)와 그룹 id (GID)를 위한 것이고 다른 지역 도메인 번호는 사이트-정의됩니다. 비-POSIX 시스템에서, 모든 지역 도메인 번호가 사이트-정의됩니다.

UUID에서 40-비트 도메인/식별자를 포함하는 기능에는 상충이 따릅니다. 다른 한편, 40비트는 노드 ID당 약 1조 개의 도메인/식별자 값을 허용합니다. 다른 한편, 버전 1에서 60비트와 비교하여 클록 값이 가장 중요한 28비트로 잘리면, 버전 2 UUID에서 클록은 버전 1에 대해 매 100나노초와 달리 매 429.49초, 약 7분에 한 번만 "틱"합니다. 그리고 버전 1에서 14비트와 비교하여 클록 시퀀스가 6비트에 불과하므로, 버전 1에 대해 16,384개 클록 시퀀스 값과 비교하여 7분 클록 틱당 노드/도메인/식별자당 64개만 고유 UUID를 생성할 수 있습니다.

Versions 3 and 5 (namespace name-based)

버전-3과 버전-5 UUID는 이름공간 식별자와 이름을 해싱함으로써 생성됩니다. 버전 3은 해싱 알고리즘으로 MD5를 사용하고, 버전 5는 SHA-1을 사용합니다.

이름공간 식별자 자체가 UUID입니다. 그 사양은 URL, 정규화된 도메인 이름, 대상 식별자, 및 X.500 고유 이름의 이름공간을 나타내기 위해 UUID를 제공합니다; 그러나 임의의 원하는 UUID는 이름공간 지정자로 사용될 수 있습니다.

주어진 이름공간과 이름에 해당하는 버전-3 UUID를 결정하기 위해, 이름공간의 UUID를 바이트 문자열로 변환하고, 입력 이름과 연결하고, 그런-다음 MD5로 해시하여, 128비트를 생성합니다. 그런-다음 6비트 또는 7비트를 고정 값, 4-비트 버전 (예를 들어, 버전 3에 대해 \(0011_2\)), 및 2-비트 또는 3-비트 UUID "변형" (예를 들어, RFC 9562 UUID를 나타내는 \(10_2\), 또는 레거시 Microsoft GUID를 나타내는 \(110_2\))으로 대체합니다. 6비트 또는 7비트가 이와 같이 미리 결정되므로, 121비트 또는 122비트만 UUID의 고유성에 기여합니다.

버전-5 UUID는 비슷하지만, MD5 대신 SHA-1이 사용됩니다. SHA-1은 160-비트 다이제스트를 생성하므로, 버전 및 변형 비트가 대체되기 전에 다이제스트가 128비트로 잘립니다.

버전-3과 버전-5 UUID는 같은 이름공간과 이름이 같은 UUID에 매핑된다는 속성이 있습니다. 어쨌든, 이름공간이나 이름은 둘 중 하나가 지정된 경우에도 무차별 대입 검색을 제외하고는 UUID에서 확인될 수 없습니다. RFC 4122는 버전 3 (MD5)보다 버전 5 (SHA-1)를 권장하고, 두 버전의 UUID를 보안 자격 증명으로 사용하지 않도록 경고합니다.

Version 4 (random)

버전 4 UUID는 무작위로 생성됩니다. 다른 UUID와 마찬가지로, 버전 4를 나타내기 위해 4비트가 사용되고, 변형을 나타내기 위해 2비트 또는 3비트가 사용됩니다 (변형 1과 2에 대해 각각 \(10_2\) 또는 \(110_2\)). 따라서, 변형 1 (즉, 대부분의 UUID)에 대해, 무작위 버전 4 UUID에는 미리 결정된 변형 및 버전 비트가 6개 있고 무작위로 생성된 부분에 122비트가 남아 총 \(2^{122}\)개, 또는 \(5.3\times 10^{36}\) (5.3 undecillion)개의 버전-4 변형-1 UUID가 가능합니다. 사용 가능한 무작위 비트가 하나 적고 변형에 3비트가 사용되므로, 가능한 버전 4, 변형 2 UUID (레거시 GUID)는 절반입니다.

RFC 9562에 따르면, 일곱 번째 옥텟의 최상위 4비트는 UUID가 따르는 버전을 나타냅니다. 즉, 세 번째 그룹의 첫 번째 16진수 자릿수는 UUIDv4에서 항상 4로 시작합니다. 시각적으로, 이것은 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx처럼 보이며, 여기서 M은 UUID 버전 필드입니다. 자릿수 N의 상위 2비트 또는 3비트는 변형을 인코딩합니다. 값은 2비트 표시에 대해 8, 9, A 또는 B이고, 3비트 표시에 대해 값 C 또는 D입니다. 예를 들어, 무작위 UUID 버전 4, 변형 2는 8D8AC610-566D-4EF0-9C22-186B2A5ED793이 될 수 있습니다.

Version 7 (timestamp and random)

버전 7 UUID (UUIDv7)는 고부하 데이터베이스와 분산 시스템의 열쇠에 대해 설계되었습니다.

UUIDv7은 약 밀리초 단위의 세분성을 갖는 48비트 빅-엔디언 Unix Epoch 타임스탬프로 시작합니다. 타임스탬프는 임의의 시간 이동 값으로 이동될 수 있습니다. 타임스탬프 바로 뒤에 버전 니블이 따라오는데, 그 값은 7이어야 합니다. 변형 비트는 10x여야 합니다. 남아있는 74비트는 무작위 시드 카운터 (선택 사항, 최소 12비트, 최대 42비트)와 무작위입니다.

두 가지 카운터 롤오버 처리 방법을 함께 사용할 수 있습니다:

카운터의 최상위, 가장 왼쪽 가드 비트에 시드가 0개입니다.
실제 시간보다 타임스탬프를 증가시키고 오버플로가 발생하면 카운터를 다시 초기화합니다.

DBMS에서 UUIDv7 생성기는 쓰레드 사이에 공유될 수 있고 (테이블이나 DBMS 인스턴스에 연결됨) 또는 쓰레드-지역화될 수 있습니다 (단조성, 지역성 및 성능이 떨어짐).

Version 8 (custom)

버전 8에는 두 가지 요구 사항만 있습니다:

변형 비트는 10x여야 합니다.
버전 니블은 8의 값이어야 합니다.

그들 요구 사항은 시스템에 버전 8 UUID임을 알려줍니다. 남아있는 122비트는 공급업체가 사용자 정의합니다. 버전 4와의 차이점은 그들 122비트는 무작위이지만, UUID 버전 8에서 122비트는 공급업체별 규칙을 따르기 때문에 무작위가 아니라는 것입니다.

Special values

Nil UUID

"nil" UUID는 UUID 00000000-0000-0000-0000-000000000000입니다; 즉, 모든 비트는 영으로 설정합니다.

Max UUID

"max" UUID는, 때때로 "omni" UUID라고 불리며, UUID FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF입니다; 즉, 모든 비트는 일로 설정합니다.

Encoding

Binary representation

처음에, Apollo Computer는 다음과 같은 와이어 형식으로 UUID를 설계했습니다:

나중에, UUID는 레거시 가족 필드와 새로운 변형 필드를 조합함으로써 확장되었습니다. 가족 필드는 과거에 0에서 13까지의 값만 사용했기 때문에, 가장 중요한 비트가 0으로 설정된 UUID가 레거시 UUID로 결정되었습니다. 이는 가족 그룹에 대한 다음 테이블을 제공합니다:

레거시 Apollo NCS UUID는 이전 테이블에 설명된 형식을 가집니다. OSF DCE UUID 변형은 RFC 9562에 설명되어 있습니다. Microsoft COM / DCOM UUID의 변형은 Microsoft 설명서에 설명되어 있습니다.

Endianess

UUID를 이진 형식으로 저장할 때, 그것들은 빅-엔디언에서 순차적으로 인코딩됩니다. 예를 들어, 00112233-4455-6677-8899-aabbccddeeff는 바이트 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff로 인코딩됩니다.

이에 대한 예외는 Microsoft의 변형 2 UUID ("GUID")입니다: 역사적으로 COM/OLE 라이브러리에서 사용되었으며, 그것들은 리틀-엔디언 형식을 사용하지만, 문자열로 포맷될 때 바이트 대시가 누락되어 UUID의 처음 세 구성 요소가 리틀 엔디언이고 마지막 두 구성 요소가 빅 엔디언인 혼합 엔디언으로 나타납니다. 예를 들어, 00112233-4455-6677-8899-aabbccddeeff는 바이트 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff로 인코딩됩니다.

Textual representation

대부분의 경우에서, UUID는 16진수 값으로 표현됩니다. 가장 많이 사용되는 형식은 8-4-4-4-12 형식, xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx로, 여기서 모든 x가 4비트를 나타냅니다. 다른 잘 알려진 형식으로는 중괄호를 갖는 8-4-4-4-12 형식, {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}, 이는 마이크로소프트의 시스템, 예를 들어, Windows에서, 또는 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx로, 여기서 모든 하이픈이 제거됩니다. 어떤 경우에서, xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx에 "0x" 접두사 또는 "h" 접미사를 붙여 16진수 값을 나타낼 수도 있습니다. 하이픈을 갖는 형식은 새로운 변형 시스템에서 도입되었습니다. 그 전에는, 레거시 Apollo 포맷이 약간 다른 포맷: 34dc23469000.0d.00.00.7c.5f.00.00.00을 사용했습니다. 첫 번째 부분은 시간 (time_high와 time_low를 합친 것)입니다. 예약된 필드는 건너뜁니다. 가족 필드는 첫 번째 점 바로 뒤에 오므로, 이 경우에서 DDS (Data Distribution Service)에 대해 0d (10진수 13)입니다. 각각 점으로 구분된 남아있는 부분은 노드 바이트입니다.

16진수 값의 소문자 형태는 일반적으로 선호되는 형식입니다. 구체적으로 특히 ITU-T Rec. X.667에 정의된 것과 같은 일부 컨텍스트에서, 텍스트를 생성할 때 소문자가 필요하지만, 대문자 버전도 허용되어야 합니다.

UUID는 128비트 정수로 표현될 수 있습니다. 예를 들어, UUID 550e8400-e29b-41d4-a716-446655440000은 113059749145936325402354257176981405696으로도 표현될 수 있습니다. UUID의 첫 번째 비트가 1로 설정되면 부호화된 값과 부호-없는 값을 모두 가질 수 있음에 주목하십시오.

UUID는 128비트 이진수로 표현될 수 있습니다. 예를 들어, UUID 550e8400-e29b-41d4-a716-446655440000은 0101010100001110100001000000000011100010100110110100000111010100101001110001011001000100011001010101010001000000000000000000으로도 표현될 수 있습니다.

RFC 9562는 "uuid" 이름공간을 등록합니다. 이를 통해 urn:uuid:550e8400-e29b-41d4-a716-446655440000과 같이 UUID에서 URN을 만들 수 있습니다. 통상적인 8-4-4-4-12 형식이 여기에 사용됩니다. 역시 urn:oid:2.25.113059749145936325402354257176981405696과 같이 UUID에서 OID URN을 만들 수도 있습니다. 이 경우에서, 부호-없는 10진수 형식이 사용됩니다. "oid" URN보다 "uuid" URN이 권장됩니다.

Collisions

충돌은 같은 UUID가 두 번 이상 생성되어 다른 참조 대상에 할당될 때 발생합니다. 네트워크 카드로부터 고유한 MAC 주소를 사용하는 표준 버전-1 및 버전-2 UUID의 경우에서, 충돌이 발생할 가능성이 낮으며, 구현이 실수로 또는 의도적으로 표준과 다를 때만 충돌 가능성이 높아집니다.

MAC 주소를 사용하여 생성된 버전-1 및 버전-2 UUID와 달리, 무작위로 생성된 노드 id, 해시-기반 버전-3 및 버전-5 UUID, 및 무작위 버전-4 UUID를 사용하는 버전-1 및 버전-2 UUID와 함께, 구현 문제 없이도 충돌이 발생할 수 있지만, 통상적으로 무시할 수 있을 만큼 확률이 작습니다. 이 확률은 생일 문제의 분석을 기반으로 정확하게 계산할 수 있습니다.

예를 들어, 최소한 한 번 이상의 충돌 확률이 50%가 되도록 생성해야 하는 무작위 버전-4 UUID의 개수는 2.71조 개로 다음과 같이 계산됩니다:

\(\displaystyle \quad n \approx \frac{1}{2} + \sqrt{\frac{1}{4} + 2 \times \ln(2) \times 2^{122}} \approx 2.71 \times 10^{18}\).

이 숫자는 약 86년 동안 초당 10억 개의 UUID를 생성하는 것과 같습니다. UUID당 16바이트로 이만큼의 UUID를 포함하는 파일은 약 45엑사바이트가 됩니다.

충돌을 발견할 확률이 p가 되기 위해 생성해야 하는 버전-4 UUID의 최소 수는 다음 공식으로 근사화됩니다:

\(\displaystyle \quad \sqrt{2 \times 2^{122} \times \ln\frac{1}{1 - p}}\).

따라서 103조 개의 버전-4 UUID에서 중복을 찾을 확률은 10억 분의 1입니다.

제조업체가 마더보드와 같은 제품에 기본 UUID를 할당한 다음 제조 프로세스 후반에 기본 UUID를 덮어쓰지 못하면 충돌이 발생합니다. 예를 들어, UUID 03000200-0400-0500-0006-000700080009는 Gigabyte 브랜드 마더보드의 여러 다른 장치에서 발생합니다.

Uses

Filesystems

중요한 사용 사례로는 ext2/ext3/ext4 파일 시스템 사용자 공간 도구 (e2fsprogs는 util-linux에 의해 제공되는 libuuid 사용), LVM, LUKS 암호화 파티션, GNOME, KDE, 및 macOS가 있으며, 이들 중 대부분은 Theodore Ts'o에 의한 원래 구현에서 파생되었습니다. "파티션 레이블"과 "파티션 UUID"는 모두 슈퍼블록에 저장됩니다. 둘 다 파티션의 일부라기보다는 파일 시스템의 일부입니다. 예를 들어 ext2–4는 UUID를 포함하고, 반면에 NTFS나 FAT32는 포함하지 않습니다. 슈퍼블록은 파일 시스템의 일부이고, 따라서 파티션 내에 완전히 포함되므로 dd if=/dev/sda1 of=/dev/sdb1을 실행하면 sda1과 sdb1 모두 같은 레이블과 UUID를 갖게 됩니다.

Remoting

Microsoft의 Component Object Model (COM)에는 여러 가지 유형의 GUID가 사용됩니다:

IID – 인터페이스 식별자; (시스템에 등록된 것은 [HKEY_CLASSES_ROOT\Interface]에 윈도우 레지스트리 내에 저장됩니다)
CLSID – 클래스 식별자; ([HKEY_CLASSES_ROOT\CLSID]에 저장됩니다)
LIBID – 유형 라이브러리 식별자; ([HKEY_CLASSES_ROOT\TypeLib]에 저장됩니다)
CATID – 카테고리 식별자; (클래스에 존재하면 해당 클래스가 [HKEY_CLASSES_ROOT\Component Categories]에 나열된 특정 클래스 카테고리에 속한다는 것을 식별합니다)

Databases

UUID는 공통적으로 데이터베이스 테이블에서 고유 열쇠로 사용됩니다. Microsoft SQL Server 버전 4 Transact-SQL에서 NEWID 함수는 표준 무작위 버전-4 UUID를 반환하고, 반면에 NEWSEQUENTIALID 함수는 다음 시스템 재부팅까지 순서대로 오름차순으로 커밋되는 UUID와 유사한 128비트 식별자를 반환합니다. Oracle Database SYS_GUID 함수는 이름에도 불구하고 표준 GUID를 반환하지 않습니다. 대신, 그것은 호스트 식별자와 프로세스 또는 스레드 식별자를 기반으로 하는 16바이트 128비트 RAW 값을 반환하는데, 이는 GUID와 다소 유사합니다. PostgreSQL에는 UUID 데이터 유형이 포함되어 있고 모듈에서 함수의 사용을 통해 대부분의 UUID 버전을 생성할 수 있습니다. MySQL은 표준 버전-1 UUID를 생성하는 UUID 함수를 제공합니다.

Combined Time-GUID

버전 3, 4, 및 5의 표준 UUID의 무작위 본성과 표준 버전 1 및 2 내의 필드 순서는 UUID가 주요 열쇠로 사용될 때 데이터베이스 지역성 또는 성능에 문제를 일으킬 수 있습니다. 예를 들어, 2002년에 Jimmy Nilsson은 열쇠로 사용되는 버전 4 UUID가 시스템 시간에 기반한 무작위적이지 않은 접미사를 포함하도록 수정되었을 때 Microsoft SQL Server에서 성능이 크게 향상되었다고 보고했습니다. Nilsson이 인정했듯이 이러한 소위 "COMB" (결합된 시간-GUID) 접근 방식은 UUID가 중복될 가능성을 상당히 높였지만, Nilsson은 응용 프로그램 내에서만 고유성을 요구했습니다. 타임스탬프가 먼저 오도록 버전 1 및 2 UUID를 재정렬하고 인코딩함으로써 삽입 성능 손실을 피할 수 있습니다.

UUID 페이로드의 COMB-계열 배열은 결국 RFC 9562에서 UUIDv6 및 UUIDv7로 표준화되었습니다.

Dawoum

(번역) Universally unique identifier