나는 UUID 의 요점을 실제로 보지 못합니다 . 충돌 확률은 사실상 nil 이지만 사실상 nil 은 불가능에 가깝지도 않습니다.
누군가 UUID를 사용할 수밖에없는 예를들 수 있습니까? 내가 본 모든 용도에서 UUID가없는 대체 디자인을 볼 수 있습니다. 물론 설계가 약간 더 복잡 할 수 있지만 적어도 실패 확률이 0이 아닌 것은 아닙니다.
UUID는 나에게 전역 변수 냄새가 난다. 전역 변수가 더 간단한 디자인을 만드는 데는 여러 가지 방법이 있지만 그저 게으른 디자인입니다.
답변
Ruby 용 UUID 생성기 / 파서를 작성 했으므로이 주제에 대해 합리적으로 잘 알고 있다고 생각합니다. 네 가지 주요 UUID 버전이 있습니다.
버전 4 UUID는 기본적으로 암호화 보안 난수 생성기에서 가져온 임의의 16 바이트에 불과하며 UUID 버전 및 변형을 식별하기위한 비트 트위들 링이 있습니다. 이들은 충돌 할 가능성이 극히 적지 만 PRNG를 사용하거나 정말, 정말, 정말, 정말, 정말, 정말 정말 불운을 겪는 경우 발생할 수 있습니다.
버전 5 및 버전 3 UUID는 각각 SHA1 및 MD5 해시 함수를 사용하여 네임 스페이스를 이미 고유 한 데이터와 결합하여 UUID를 생성합니다. 예를 들어 URL에서 UUID를 생성 할 수 있습니다. 여기서 충돌은 기본 해시 함수에도 충돌이있는 경우에만 가능합니다.
버전 1 UUID가 가장 일반적입니다. 이들은 네트워크 카드의 MAC 주소 (스푸핑되지 않는 한 고유해야 함)와 타임 스탬프, 일반적인 비트 트위들 링을 사용하여 UUID를 생성합니다. MAC 주소가없는 시스템의 경우 암호화 보안 난수 생성기로 6 노드 바이트가 생성됩니다. 두 개의 UUID가 타임 스탬프가 이전 UUID와 일치 할만큼 충분히 빠르게 생성되는 경우 타임 스탬프는 1 씩 증가합니다. 다음 중 하나가 발생하지 않는 한 충돌이 발생해서는 안됩니다. MAC 주소가 스푸핑되었습니다. 두 개의 서로 다른 UUID 생성 응용 프로그램을 실행하는 하나의 컴퓨터는 정확히 같은 순간에 UUID를 생성합니다. 네트워크 카드가 없거나 MAC 주소에 대한 사용자 수준 액세스 권한이없는 두 대의 컴퓨터에는 동일한 임의 노드 시퀀스가 지정되고 정확히 같은 순간에 UUID를 생성합니다.
현실적으로 이러한 이벤트는 단일 애플리케이션의 ID 공간 내에서 우연히 발생하지 않습니다. 예를 들어 인터넷 규모의 ID를 받아들이거나 ID 충돌시 악의적 인 개인이 악의적 인 작업을 수행 할 수있는 신뢰할 수없는 환경에서 ID를 받아들이지 않는 한 걱정할 필요가 없습니다. 나와 동일한 버전 4 UUID를 생성하는 경우 대부분의 경우 문제가되지 않는다는 점을 이해하는 것이 중요합니다. 귀하와 완전히 다른 ID 공간에 ID를 생성했습니다. 내 응용 프로그램은 충돌에 대해 알지 못하므로 충돌은 중요하지 않습니다. 솔직히 말해서 악의적 인 행위자가없는 단일 애플리케이션 공간에서는 충돌이 발생하기 훨씬 전에 지구상의 모든 생명체가 멸종 될 것입니다. 심지어 버전 4 UUID에서도 마찬가지입니다.
또한 2 ^ 64 * 16은 256 엑사 바이트입니다. 에서와 같이 단일 애플리케이션 공간에서 ID 충돌 가능성이 50 % 발생하기 전에 256 엑사 바이트 상당의 ID를 저장해야합니다.
답변
UUID가 구입하는 것은 그렇지 않으면 매우 어려운 일이며 중앙 기관과 협의하거나 조정하지 않고도 고유 한 식별자를 얻는 것 입니다. 일종의 관리 인프라없이 이러한 것을 얻을 수 있다는 일반적인 문제는 UUID가 해결하는 문제입니다.
생일 패러독스에 따르면 2 ^ 64 개의 UUID가 생성되면 UUID 충돌이 발생할 확률이 50 %라고 읽었습니다. 이제 2 ^ 64는 꽤 큰 숫자이지만 50 %의 충돌 확률은 너무 위험 해 보입니다 (예를 들어, 5 %의 충돌 확률이 있기 전에 얼마나 많은 UUID가 존재해야하는지-너무 큰 확률로 보입니다) .
그 분석의 문제는 두 가지입니다.
-
UUID는 완전히 무작위가 아닙니다. UUID에는 시간 및 / 또는 위치 기반의 주요 구성 요소가 있습니다. 따라서 실제 충돌 가능성을 가지려면 충돌하는 UUID를 서로 다른 UUID 생성기에서 정확히 동시에 생성해야합니다. 여러 UUID가 동시에 생성 될 수있는 합리적인 기회가 있지만,이 아주 작은 UUID 집합 간의 충돌 가능성을 거의 불가능하게 만드는 다른 건크 (위치 정보 또는 임의 비트 포함)가 충분하다고 말하고 싶습니다. .
-
엄밀히 말하면 UUID는 비교할 수있는 다른 UUID 세트 중에서 고유해야합니다. 데이터베이스 키로 사용할 UUID를 생성하는 경우 동일한 UUID가 COM 인터페이스를 식별하는 데 사용되는 악의적 인 대체 유니버스의 다른 위치는 중요하지 않습니다. Alpha-Centauri에 “Michael Burr”라는 이름의 누군가 (또는 무언가)가 있어도 혼동을 일으키지 않는 것처럼 말입니다.
답변
모든 것이 실패 할 확률이 0이 아닙니다. 나는 UUID의 충돌보다 문제가 발생할 가능성이 훨씬 더 높다 (즉, 당신이 생각할 수있는 거의 모든 것)에 집중할 것이다.
답변
“합리적으로”또는 “효과적으로”에 대한 강조 : 현실 세계가 작동하는 방식이면 충분합니다. “실질적으로 고유 한”것과 “정말로 고유 한”사이의 간격을 메우는 데 관련된 계산 작업의 양은 엄청납니다. 고유성은 수익이 감소하는 곡선입니다. 그 곡선의 어떤 지점에서 “충분히 고유 한”것이 여전히 적당한 지점 사이에 선이 있고, 우리는 매우 가파르게 곡선을 만듭니다. 더 많은 고유성을 추가하는 비용이 상당히 커집니다. 무한한 고유성은 무한한 비용이 있습니다.
UUID / GUID는 비교적 말해서 보편적으로 고유하다고 합리적으로 가정 할 수있는 ID를 생성하는 계산적으로 빠르고 쉬운 방법 입니다. 이것은 이전에 연결되지 않은 시스템의 데이터를 통합해야하는 많은 시스템에서 매우 중요합니다. 예 : 두 개의 서로 다른 플랫폼에서 실행되는 콘텐츠 관리 시스템이 있지만 어느 시점에서 한 시스템에서 다른 시스템으로 콘텐츠를 가져와야하는 경우. ID가 변경되는 것을 원하지 않으므로 시스템 A의 데이터 간 참조는 그대로 유지되지만 시스템 B에서 생성 된 데이터와의 충돌은 원하지 않습니다. UUID가이를 해결합니다.
답변
UUID를 반드시 생성 할 필요는 없습니다. 그러나 오프라인 사용자가 각각 매우 낮은 충돌 가능성으로 키를 생성 할 수 있는 표준을 갖는 것이 편리합니다 .
이것은 데이터베이스 복제 해결 등에 도움이 될 수 있습니다.
것이 쉬울 것이다 온라인 사용자가 오버 헤드 또는 충돌의 가능성이없는 무언가에 대한 고유 키를 생성하지만이 UUID가가 무엇 없습니다.
어쨌든, Wikipedia에서 가져온 충돌 확률에 대한 단어 :
이 수치를 살펴보면 연간 운석에 맞을 위험은 170 억분의 1로 추정되며, 이는 1 년에 수십조 개의 UUID를 생성하고 하나의 중복을 가질 확률과 동일합니다. 즉, 향후 100 년 동안 매초 10 억 UUID를 생성 한 후에야 하나의 복제본 만 생성 할 확률은 약 50 %가됩니다.
답변
고전적인 예는 두 데이터베이스간에 복제하는 경우입니다.
DB (A)는 int ID 10의 레코드를 삽입하고 동시에 DB (B)는 ID 10의 레코드를 생성합니다. 이것은 충돌입니다.
UUID를 사용하면 일치하지 않으므로 발생하지 않습니다. (거의 확실히)
답변
또한 신체의 모든 입자가 앉아있는 의자를 통해 동시에 터널링되어 갑자기 바닥에 앉아있는 자신을 발견 할 확률이 0이 아닙니다.
그것에 대해 걱정하십니까?
