디자인의 일부로 UUID를 사용해야하는 경우는 언제입니까?

나는 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가 존재해야하는지-너무 큰 확률로 보입니다) .

그 분석의 문제는 두 가지입니다.

1. UUID는 완전히 무작위가 아닙니다. UUID에는 시간 및 / 또는 위치 기반의 주요 구성 요소가 있습니다. 따라서 실제 충돌 가능성을 가지려면 충돌하는 UUID를 서로 다른 UUID 생성기에서 정확히 동시에 생성해야합니다. 여러 UUID가 동시에 생성 될 수있는 합리적인 기회가 있지만,이 아주 작은 UUID 집합 간의 충돌 가능성을 거의 불가능하게 만드는 다른 건크 (위치 정보 또는 임의 비트 포함)가 충분하다고 말하고 싶습니다. .

2. 엄밀히 말하면 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이 아닙니다.

그것에 대해 걱정하십니까?

UUID를 피하는 계획이 있습니다. 서버를 어딘가에 설치하고 소프트웨어의 일부가 보편적으로 고유 한 식별자를 원할 때마다 해당 서버에 접속하여 하나를 전달하도록합니다. 단순한!

우리가 노골적인 악의를 무시하더라도 실제적인 문제가 있다는 점을 제외하면. 특히 해당 서버는 인터넷의 일부에서 실패하거나 연결할 수 없게 될 수 있습니다. 서버 장애를 처리하려면 복제가 필요하며, 이는 제대로 이해 하기 가 매우 어렵고 (합의 구축이 어색한 이유는 Paxos 알고리즘에 대한 문헌 참조) 매우 느립니다. 모든 서버가 '인터넷의 특정 부분에서 도달 할 수없는 경우 또한, 어느 것도 해당 서브넷에 연결된 클라이언트는 모든 새로운 ID를 기다리고있을 것이기 때문에 아무것도 할 수 없습니다.

따라서 ... 간단한 확률 알고리즘을 사용하여 지구 수명 동안 실패 할 가능성이없는 파일을 생성하거나 배포 PITA가 될 주요 인프라를 구축하고 자주 실패 할 수 있습니다. 나는 내가 어느 것을 갈지 압니다.

충돌 가능성에 대한 모든 이야기를 이해하지 못합니다. 충돌은 신경 쓰지 않습니다. 그래도 성능에 관심이 있습니다.

https://dba.stackexchange.com/a/119129/33649

UUID는 매우 큰 테이블에 대한 성능 재앙입니다. (200K 행은 "매우 크지"않습니다.)

CHARCTER SET이 utf8 일 때 # 3은 정말 나쁩니다. CHAR (36)은 108 바이트를 차지합니다!

UUID (GUID)는 매우 "무작위"입니다. 큰 테이블에서 UNIQUE 또는 PRIMARY 키로 사용하는 것은 매우 비효율적입니다. 이는 새로운 UUID를 INSERT하거나 UUID로 SELECT 할 때마다 테이블 / 인덱스를 건너 뛰어야하기 때문입니다. 테이블 / 인덱스가 너무 커서 캐시에 맞지 않는 경우 (RAM보다 작아야하는 innodb_buffer_pool_size 참조 (일반적으로 70 %)) '다음'UUID가 캐시되지 않아 디스크 히트가 느려질 수 있습니다. 테이블 / 인덱스가 캐시보다 20 배 크면 적중의 1/20 (5 %) 만 캐시됩니다. 즉, I / O 바인딩됩니다.

따라서 다음 중 하나가 아니면 UUID를 사용하지 마십시오.

"작은"테이블이 있거나 다른 위치에서 고유 한 ID를 생성하기 때문에 테이블이 실제로 필요합니다 (다른 방법을 찾지 못함). UUID에 대한 추가 정보 : http://mysql.rjweb.org/doc.php/uuid (표준 36 자 UUID와 BINARY (16) 간의 변환 기능을 포함합니다.)

동일한 테이블에 UNIQUE AUTO_INCREMENT와 UNIQUE UUID를 모두 갖는 것은 낭비입니다.

INSERT가 발생하면 모든 고유 / 기본 키의 중복 여부를 확인해야합니다. InnoDB의 PRIMARY KEY를 필요로하는 데는 고유 키가 충분합니다. BINARY (16) (16 바이트)는 다소 부피가 크지 만 (PK로 만드는 것에 대한 논쟁) 그렇게 나쁘지는 않습니다. 보조 키가 있으면 부피가 중요합니다. InnoDB는 PK를 각 보조 키 끝에 자동으로 붙입니다. 여기서 주된 교훈은 특히 매우 큰 테이블의 경우 보조 키의 수를 최소화하는 것입니다. 비교를 위해 : INT UNSIGNED는 0.4 억 범위의 4 바이트입니다. BIGINT는 8 바이트입니다.

예를 들어 간단한 데이터베이스 응용 프로그램에 대한 대안을 살펴보면 새 개체를 만들기 전에 매번 데이터베이스를 쿼리해야하는 경우 UUID를 사용하면 시스템의 복잡성을 효과적으로 줄일 수 있다는 것을 곧 알게 될 것입니다. 허용됨-int 키를 사용하는 경우 32 비트이며 128 비트 UUID의 1/4에 저장됩니다. 허용됨-UUID 생성 알고리즘은 단순히 숫자를 증가시키는 것보다 더 많은 계산 능력을 사용합니다. 하지만-누가 신경 쓰나요? 고유 한 번호를 할당하기 위해 "권한"을 관리하는 오버 헤드는 의도 한 고유성 ID 공간에 따라 훨씬 더 큽니다.

UUID == 게으른 디자인

나는 당신의 싸움을 선택하는 것에 동의하지 않습니다. 중복 UUID가 통계적으로 불가능하고 수학이 입증 된 경우 왜 걱정할까요? 작은 N UUID 생성 시스템을 중심으로 설계하는 데 시간을 보내는 것은 비현실적입니다. 시스템을 개선 할 수있는 다른 방법은 항상 12 가지가 있습니다.

마지막 작업에서 우리는 UUID로 고유하게 식별 된 제 3 자로부터 개체를 가져 왔습니다. 나는 UUID-> long integer lookup 테이블에 넣고 long integer를 기본 키로 사용했습니다.

버전 1 알고리즘을 사용하면 동일한 MAC 주소에서 밀리 초당 10 UUID 미만이 생성된다는 제약 조건 하에서 충돌이 불가능한 것 같습니다.

개념적으로 UUID에 대한 원래 (버전 1) 생성 체계는 UUID 버전을 UUID를 생성하는 컴퓨터의 MAC 주소 및 서양에서 그레고리력을 채택한 이후 100 나노초 간격의 수와 연결하는 것이 었습니다. . 실제로 실제 알고리즘은 더 복잡합니다. 이 계획은 충분히 '불투명'하지 않다는 점에서 비판을 받아 왔습니다. UUID를 생성 한 컴퓨터의 신원과 생성 시간을 모두 보여줍니다.

내가 어떻게 작동하는지 잘못 해석하면 누군가 나를 바로 잡습니다.

UUID가 충돌 할 수 있기 때문에 (어느 정도는 아주 작은 확률로) 잘못된 설계라고 말하는 사람들에게 DB 생성 키는 충돌하지 않을 것입니다. -예측 된 필요는 UUID4 충돌 가능성보다 훨씬 더 높습니다. 우리는 알고 DB를 다시 만들 경우 다시 1에서 ID를 시작하는 것, 얼마나 많은 우리는 우리가 확실히 우리가 이제까지 필요로하지 않을 것있을 때 테이블을 재 작성해야했다? 언젠가 알려지지 않은 사람들로 인해 물건이 잘못되기 시작하면 UUID 안전에 돈을 걸었습니다.

UUID를 요구하는 다른 사람의 API를 사용해야하는 경우를 제외하고는 물론 항상 다른 솔루션이 있습니다. 그러나 이러한 대안 은 UUID가 수행하는 모든 문제를 해결할 수 있습니까? 한 번에 모든 문제를 해결할 수 있었는데 각각 다른 문제를 해결하기 위해 더 많은 해킹 레이어를 추가하게 될까요?

예, 이론적으로 UUID가 충돌 할 수 있습니다. 다른 사람들이 지적했듯이 고려할 가치가 없을 정도로 말도 안되는 일입니다. 그것은 지금까지 일어난 적이 없으며 아마도 결코 일어나지 않을 것입니다. 잊어 버려.

충돌을 피하는 가장 "명백한"방법은 단일 서버가 모든 삽입에 대해 고유 한 ID를 생성하도록하는 것입니다. 이는 분명히 심각한 성능 문제를 일으키고 오프라인 생성 문제를 전혀 해결하지 못합니다. 죄송합니다.

다른 "명백한"솔루션은 고유 번호 블록을 미리 전달하는 중앙 기관으로, 이는 본질적으로 생성 시스템의 MAC 주소를 사용하여 (IEEE OUI를 통해) UUID V1이 수행하는 작업입니다. 그러나 중복 MAC 주소는 모든 중앙 기관이 결국 망가지기 때문에 발생하므로 실제로 UUID V4 충돌보다 훨씬 더 가능성이 높습니다. 죄송합니다.

UUID 사용에 대한 가장 좋은 주장은 UUID가 "너무 크다"는 것입니다. 그러나 (상당히) 더 작은 체계는 가장 흥미로운 문제를 해결하지 못할 것입니다. UUID의 크기는 바로 이러한 문제를 해결하는 데 유용함의 내재 된 부작용입니다.

UUID가 제공하는 것을 필요로 할만큼 문제가 크지 않을 수 있으며,이 경우 다른 것을 자유롭게 사용하십시오. 그러나 문제가 예상치 않게 증가하면 (대부분의 경우) 나중에 전환하게되며 처음부터 사용하지 않는다는 이유로 스스로를 걷어차 게됩니다. 성공을위한 디자인만큼이나 쉬운데 실패를위한 디자인을하는 이유는 무엇입니까?

UUID는 전역 변수와 관련된 모든 잘못된 코딩 관행을 구현합니다. 더 나쁜 것은 UUID가 다른 키트에 배포 될 수있는 수퍼 글로벌 변수이기 때문입니다.

최근에 정확한 교체 모델로 프린터를 교체하는 것과 같은 문제가 발생했으며 클라이언트 소프트웨어가 작동하지 않는 것으로 나타났습니다.