GUID 충돌이 가능합니까?

SQL Server 2000에서 연결된 응용 프로그램을 사용하는 각 사용자에 대해 GUID를 사용하는 데이터베이스에서 작업하고 있습니다. 어쨌든 두 명의 사용자가 동일한 GUID를 사용했습니다. Microsoft는 알고리즘을 사용하여 콜리 전을 유발할 가능성이 극히 적은 임의의 GUID를 생성하지만 충돌은 여전히 ​​가능하다는 것을 알고 있습니다.

기본적으로 누군가 당신의 데이터베이스를 다루는 것 같습니다. 버전 GUID에 따라 값을 사용하는 것이 고유하거나 (버전 1 GUID와 같은 것) 고유하거나 예측할 수없는 것 (버전 4 GUID와 같은 것)입니다. NEWID () 함수에 대한 SQL Server의 구현은 128 비트 난수를 사용하는 것으로 보이므로 충돌이 발생하지 않습니다.

충돌 가능성이 1 %이면 약 2,600,000,000,000,000,000 GUID 를 생성해야합니다 .

기본적으로 그들은 불가능합니다! 천문학적으로 가능성은 낮다 .

하지만 ... 나는 내가 알고있는 세계에서 유일하게 GUID가 한 번만있는 사람 입니다.

그리고 나는 그것을 확신하고 실수가 아니라고 확신합니다.

Pocket PC에서 실행되는 작은 응용 프로그램에서는 작업이 끝날 때 GUID가 생성 된 명령을 실행해야했습니다. 서버에서 실행 된 명령은 실행 날짜와 함께 서버의 명령 테이블에 저장되었습니다. 어느 날 디버깅 할 때 모듈 명령 (새로 생성 된 GUID가 첨부 된)을 발행했지만 아무 일도 일어나지 않았습니다. 작업을 시작할 때 guid가 한 번만 생성되었으므로 동일한 guid로 다시 수행했으며 명령이 실행되지 않는 이유를 찾으려고 아무것도하지 않았습니다. 명령 테이블을 확인했습니다. 현재 GUID와 동일한 GUID가 3 주 전에 삽입되었습니다. 이것을 믿지 않고 2 주 백업에서 데이터베이스를 복원했으며 guid가있었습니다. 코드를 확인하면 새로운 guid가 의심의 여지없이 새로 생성되었습니다.

편집 :이 발생 가능성을 크게 높일 수있는 몇 가지 요소가 있으며 응용 프로그램이 PocketPC 에뮬레이터에서 실행 중이며 에뮬레이터에 상태 저장 기능이있어 상태가 복원 될 때마다 현지 시간도 복원됩니다. guid는 내부 타이머를 기반으로합니다 .... 또한 컴팩트 프레임 워크를위한 guid 생성 알고리즘은 COM보다 덜 완벽 할 수 있습니다.

그것들은 이론적으로는 가능하지만 3.4E38의 가능한 숫자로 1 년에 수십 조의 GUID를 생성하면 한 번의 복제 가능성은 0.00000000006 ( Source )입니다.

두 명의 사용자가 동일한 GUID를 사용하면 프로그램에 데이터가 복사되거나 공유되는 버그가 있다고 생각합니다.

먼저 두 GUID의 충돌 가능성을 살펴 보겠습니다. 다른 답변에서 언급했듯이 생일 역설 때문에 2 ^ 128 (10 ^ 38)의 1은 아닙니다. 즉, 두 GUID가 충돌 할 확률이 2 ^ 64 (10 ^ 19) 이것은 훨씬 작습니다. 그러나 이것은 여전히 ​​매우 많으며 합리적인 수의 GUID를 사용한다고 가정 할 때 충돌 확률이 낮습니다.

또한 많은 사람들이 생각하는 것처럼 GUID에는 타임 스탬프 또는 MAC 주소가 포함되어 있지 않습니다. 이것은 v1 GUID에 해당되었지만 이제는 의사 난수 인 v4 GUID가 사용되는데, 이는 더 이상 시간과 기계에 고유하지 않기 때문에 충돌 가능성이 더 높음을 의미합니다.

따라서 본질적으로 대답은 그렇습니다. 충돌이 가능합니다. 그러나 그들은 가능성이 거의 없습니다.

편집 : 2 ^ 64로 고정

두 개의 임의 GUID 충돌 가능성 (10 ^ 38에서 ~ 1)은 손상된 TCP / IP 패킷을 감지하지 못할 확률보다 낮습니다 (10 ^ 10에서 ~ 1). http://wwwse.inf.tu-dresden.de/data/courses/SE1/SE1-2004-lec12.pdf , 11 페이지 이것은 디스크 드라이브, CD 드라이브 등에도 적용됩니다.

GUID는 통계적으로 고유하며 db에서 읽은 데이터는 통계적으로 만 정확합니다.

나는 고려할 것 오캄의 면도날 이 경우에 좋은 가이드로. GUID 충돌이 발생할 가능성은 거의 없습니다. 버그가 있거나 데이터를 엉망으로 만드는 사람이 훨씬 많습니다.

Wikipedia의 글로벌 고유 식별자 (Globally Unique Identifier) 기사를 참조하십시오. GUID를 생성하는 방법에는 여러 가지가 있습니다. 분명히 오래된 (?) 방식은 Mac 주소, 매우 짧은 단위의 타임 스탬프 및 고유 한 카운터 (동일한 컴퓨터에서 빠른 세대를 관리하기 위해)를 사용했기 때문에 복제하는 것은 거의 불가능합니다. 그러나이 GUID는 사용자를 추적하는 데 사용될 수 있기 때문에 삭제되었습니다 ...

Microsoft에서 사용하는 새로운 알고리즘에 대해 잘 모르겠습니다 (이 기사에서는 GUID 시퀀스를 예측할 수 있다고 말하지만 더 이상 타임 스탬프를 사용하지 않는 것 같습니다. 위에 링크 된 Microsoft 기사에 다른 내용이 나와 있습니다 ...).

이제 GUID는 이름이 전 세계적으로 고유하도록 신중하게 설계되었으므로 불가능하거나 매우 낮은 확률로 위험에 처할 것입니다. 나는 다른 곳을 볼 것이다.

MAC 주소가 중복 된 이더넷 카드가있는 두 대의 Win95 시스템은 엄격하게 제어 된 조건에서 특히 GUI (예 : 건물의 전원이 꺼지고 정확히 동시에 부팅되는 경우)에서 중복 GUIDS를 발행합니다.

나는 "나는 네트워킹 사람이 아니기 때문에 다음과 같이 완전히 일관되지 않은 문장을 만들 수있다."라는 제목을 붙일 것이다.

일리노이 주립 대학에서 일할 때, 서로 다른 시간에 주문 된 두 개의 Dell 데스크탑이있었습니다. 첫 번째는 네트워크에 배치했지만 두 번째는 네트워크에 배치하려고 시도 할 때 심각한 오류가 발생하기 시작했습니다. 많은 문제 해결 후 두 시스템에서 동일한 GUID를 생성하는 것으로 확인되었습니다 (정확히 무엇을 알지 못하지만 네트워크에서 모두 사용할 수 없게 만들었습니다). 실제로 Dell은 두 시스템을 모두 결함이있는 것으로 교체했습니다.

GUID가 마술적이고 독창적이라고 보장되는 기분이 좋은 대답을 알고 있지만 실제로 대부분의 GUID는 121 비트의 난수 (7 비트는 형식화에 낭비 됨)입니다. 큰 난수를 사용하는 것이 편하지 않다면 GUID를 사용하는 것이 불편하지 않아야합니다.

GUID를 생성하는 데 사용 된 코드에 버그가있을 수 있습니까? 물론 가능합니다. 그러나 대답은 컴파일러 버그와 동일합니다. 자신의 코드는 버그가 많을 가능성이 높으므로 먼저 살펴보십시오.

물론 가능합니다. 가능성은 없지만 가능합니다.

동일한 머신이 모든 GUID (서버)를 생성하므로 머신 특정 정보를 기반으로하는 많은 "임의성"이 손실됩니다.

grins을 위해 다음 스크립트를 사용해보십시오 ... (SQL 2005에서 작동, 2000에 대해서는 확실하지 않음)

declare @table table
(
    column1 uniqueidentifier default (newid()),
    column2 int,
    column3 datetime default (getdate())
)

declare @counter int

set @counter = 1

while @counter <= 10000
begin
    insert into @table (column2) values (@counter)
    set @counter = @counter + 1
end

select * from @table

select * from @table t1 join @table t2 on t1.column1 = t2.column1 and t1.column2 != t2.column2

이 작업을 반복적으로 실행하면 (1 초 미만 소요) 매우 짧은 시간 간격이 있어도 첫 번째 선택에서 상당히 넓은 범위가 생성됩니다. 지금까지 두 번째 선택은 아무것도 생성하지 않았습니다.

사용자에게 네트워크 카드가있는 다른 시스템이있는 경우에는 불가능하지만 여전히 거의 이론적 인 위험이 아닙니다.

개인적으로 나는 GUID 충돌보다는 버그 일 가능성이 더 높은 다른 곳을보고 싶습니다 ...

물론 GUID를 더 짧게 만들기 위해 비트를 잘라 내지 않습니다.

물론 가능하고 가능할 수도 있습니다. 각 GUID가 가능한 숫자 공간의 임의 부분에있는 것은 아닙니다. 두 개의 스레드가 하나를 동시에 생성하려고 시도 할 때 세마포어가있는 중앙 집중식 GUID 기능을 사용하지 않으면 동일한 값으로 끝날 수 있습니다.

GUID 충돌을 다음과 같은 방법으로 생성하는 경우 GUID 충돌이 발생할 가능성이 거의 없습니다. NEWID()SQL Server 함수 기능을 (물론 다른 대답이 강조했듯이 가능할 수도 있음). 그들이 지적하지 않은 한 가지는 실제로 브라우저에서 JavaScript로 GUID를 생성하는 경우 실제로 충돌이 발생할 가능성이 높다는 것입니다. 다른 브라우저의 RNG에 문제가있을뿐만 아니라 Google 스파이더가 그러한 기능의 결과를 캐시하는 것처럼 보이는 문제가 발생하여 동일한 GUID를 시스템에 반복적으로 전달합니다.

자세한 내용은 여기에서 다양한 답변을 참조하십시오.

JavaScript에서 UUID를 생성 할 때 충돌이 발생합니까?