Kiedy naprawdę jesteś zmuszony do używania UUID jako części projektu?


124

Naprawdę nie widzę sensu UUID . Wiem, że prawdopodobieństwo kolizji jest praktycznie zerowe , ale w rzeczywistości zero nie jest nawet bliskie niemożliwości.

Czy ktoś może podać przykład, w którym nie masz innego wyjścia, jak tylko użyć UUID? Ze wszystkich zastosowań, które widziałem, widzę alternatywny projekt bez UUID. Oczywiście projekt może być nieco bardziej skomplikowany, ale przynajmniej nie ma niezerowego prawdopodobieństwa niepowodzenia.

UUID pachnie dla mnie jak zmienne globalne. Istnieje wiele sposobów, w jakie zmienne globalne ułatwiają projektowanie, ale jest to po prostu leniwy projekt.


23
Wszystko ma niezerową szansę niepowodzenia. Chciałbym skupić się na znacznie bardziej prawdopodobne problemy (czyli prawie wszystko można myśleć) niż kolizji UUID
DanSingerman

16
W rzeczywistości „efektywnie zero” jest bardzo bliskie niemożliwości.
mqp

21
Nie, w rzeczywistości jest to nieskończenie dalekie od niemożliwości
pirolistyczny

32
@Pirolistic, kiedy zaczynasz rzucać w słowa takie jak „nieskończoność”, opuściłeś świat tworzenia oprogramowania. Teoria informatyki to zupełnie inna dyskusja niż pisanie prawdziwego oprogramowania.
Rex M

2
Zamknę głównie dlatego, że sha1 gita przekonał mnie o dobroci haszyszu
Pyrolistic

Odpowiedzi:


618

Napisałem generator / parser UUID dla Rubiego, więc uważam się za dość dobrze poinformowanego na ten temat. Istnieją cztery główne wersje UUID:

Identyfikatory UUID w wersji 4 to w zasadzie tylko 16 bajtów losowości pobieranych z kryptograficznie bezpiecznego generatora liczb losowych, z pewnymi zmianami bitów w celu zidentyfikowania wersji i wariantu UUID. Jest bardzo mało prawdopodobne, aby zderzyły się, ale może się zdarzyć, jeśli użyjesz PRNG lub jeśli po prostu masz naprawdę, naprawdę, naprawdę, naprawdę pecha.

Identyfikatory UUID wersji 5 i wersji 3 używają odpowiednio funkcji skrótu SHA1 i MD5 do łączenia przestrzeni nazw z fragmentem już unikalnych danych w celu wygenerowania identyfikatora UUID. Pozwoli to na przykład stworzyć UUID z adresu URL. Kolizje są tutaj możliwe tylko wtedy, gdy bazowa funkcja skrótu również ma kolizję.

Najpopularniejsze są identyfikatory UUID wersji 1. Używają adresu MAC karty sieciowej (który, o ile nie jest sfałszowany, powinien być unikalny), a także znacznika czasu i zwykłego manipulowania bitami w celu wygenerowania UUID. W przypadku maszyny, która nie ma adresu MAC, 6 bajtów węzłów jest generowanych za pomocą bezpiecznego kryptograficznie generatora liczb losowych. Jeśli dwa identyfikatory UUID są generowane sekwencyjnie na tyle szybko, że znacznik czasu pasuje do poprzedniego identyfikatora UUID, znacznik czasu jest zwiększany o 1. Kolizje nie powinny wystąpić, chyba że nastąpi jedno z poniższych: Adres MAC jest sfałszowany; Jedna maszyna z dwoma różnymi aplikacjami generującymi UUID generuje UUID dokładnie w tym samym momencie; Dwie maszyny bez karty sieciowej lub bez dostępu do adresu MAC na poziomie użytkownika otrzymują tę samą losową sekwencję węzłów i generują identyfikatory UUID dokładnie w tym samym momencie;

Realistycznie, żadne z tych zdarzeń nie występuje przypadkowo w przestrzeni identyfikatora pojedynczej aplikacji. O ile nie akceptujesz identyfikatorów w, powiedzmy, całym Internecie lub w niezaufanym środowisku, w którym złośliwe osoby mogą być w stanie zrobić coś złego w przypadku kolizji tożsamości, po prostu nie należy się tym martwić. Ważne jest, aby zrozumieć, że jeśli zdarzy ci się wygenerować ten sam identyfikator UUID w wersji 4 co ja, w większości przypadków nie ma to znaczenia. Wygenerowałem ID w zupełnie innej przestrzeni ID niż Twoja. Moja aplikacja nigdy nie dowie się o kolizji, więc kolizja nie ma znaczenia. Szczerze mówiąc, w pojedynczej przestrzeni aplikacji bez złośliwych aktorów wymieranie wszelkiego życia na Ziemi nastąpi na długo przed kolizją, nawet na UUID w wersji 4, nawet jeśli

Ponadto 2 ^ 64 * 16 to 256 eksabajtów. Tak jak w przypadku, należałoby przechowywać identyfikatory o wartości 256 eksabajtów, aby mieć 50% szans na kolizję identyfikatorów w pojedynczej przestrzeni aplikacji.


8
To zdecydowanie najlepsze wyjaśnienie. Nie wiem, dlaczego to nie jest głosowane na szczyt. Uznanie dla ciebie Sporkmonger.
Brad Barker

1
@Chamnap Napisałem UUIDTools. Identyfikatory UUID można konwertować na liczbę całkowitą lub ich postać surowego bajtu i byłyby znacznie mniejsze jako binarne.
Bob Aman,

1
@Chamnap uuid.rawpoda ci ciąg bajtów. Ta hashmetoda nie jest dla ciebie przydatna. Jest używany do tablic mieszających i operacji porównania wewnętrznie w Rubim. Wszystkie metody konwersji do iz różnych reprezentacji UUID są zdefiniowane jako metody klasowe i powinny być poprzedzone przedrostkiem "parse".
Bob Aman

3
@BobAman w 1990 roku miałem 12 kolizji UUID w systemie Aegis, okazało się, że jest to wadliwy FPU, ale pomyślałem, że dam ci znać, że może się zdarzyć (nie wydarzyło się to jednak inaczej niż w ciągu ostatnich 30 lat programowania) . Ładne wyjaśnienie, przy okazji, to jest teraz mój post refaktyczny UUID, który powinienem dać ludziom :)
GMasucci

2
@kqr Masz całkowitą rację, że to problem urodzin, jednak w przypadku kodu n-bitowego problem paradoksu urodzin zmniejsza się do 2 ^ (n / 2), co w tym przypadku wynosi 2 ^ 64, jak stwierdziłem w mojej odpowiedzi .
Bob Aman

69

To, co kupujesz za UUID, a jest bardzo trudne do zrobienia w inny sposób, to uzyskanie unikalnego identyfikatora bez konieczności konsultacji lub koordynacji z organem centralnym . Ogólnym problemem związanym z uzyskaniem czegoś takiego bez jakiejś zarządzanej infrastruktury jest problem rozwiązany przez UUID.

Czytałem, że zgodnie z paradoksem urodzinowym prawdopodobieństwo wystąpienia kolizji UUID wynosi 50% po wygenerowaniu 2 ^ 64 UUID. Teraz 2 ^ 64 to całkiem duża liczba, ale 50% szans na kolizję wydaje się zbyt ryzykowne (na przykład, ile UUID musi istnieć, zanim istnieje 5% szans na kolizję - nawet to wydaje się zbyt duże prawdopodobieństwo) .

Problem z tą analizą jest dwojaki:

  1. Identyfikatory UUID nie są całkowicie losowe - istnieją główne składniki UUID oparte na czasie i / lub lokalizacji. Aby mieć realną szansę na kolizję, kolidujące UUID muszą być generowane dokładnie w tym samym czasie z różnych generatorów UUID. Powiedziałbym, że chociaż istnieje rozsądna szansa, że ​​kilka UUID może zostać wygenerowanych w tym samym czasie, jest wystarczająco dużo innych gunk (w tym informacji o lokalizacji lub losowych bitów), aby prawdopodobieństwo kolizji między tym bardzo małym zestawem UUID było prawie niemożliwe .

  2. Ściśle mówiąc, identyfikatory UUID muszą być unikalne w zestawie innych identyfikatorów UUID, z którymi można je porównywać. Jeśli generujesz UUID, który ma być używany jako klucz bazy danych, nie ma znaczenia, czy gdzieś indziej w złym alternatywnym wszechświecie ten sam UUID jest używany do identyfikacji interfejsu COM. Tak jak nie spowoduje to zamieszania, jeśli na Alpha-Centauri jest ktoś (lub coś) innego o imieniu „Michael Burr”.


1
Konkretny przykład? UUID COM / DCE - nie ma uprawnień do ich przypisywania i nikt nie chciał wziąć na siebie odpowiedzialności i / lub nikt nie chciał, aby był organ. Rozproszone bazy danych, które nie mają niezawodnych linków i nie mają wzorca.
Michael Burr

3
Bardziej konkretny przykład - aplikacja bankowa. Jest zainstalowanych wiele centrów danych, po jednym dla każdego kraju, a każde centrum danych ma bazę danych. Wiele instalacji ma na celu przestrzeganie różnych przepisów. W całym zestawie może znajdować się tylko jeden rekord klienta dla każdego klienta .....
Vineet Reynolds

(Kontynuacja poprzedniego komentarza) Musisz mieć centralny serwer do generowania identyfikatorów klienta do celów ogólnych raportowania i śledzenia (we wszystkich instalacjach) lub mieć indywidualne instalacje generujące UUID, które będą służyć jako identyfikatory klientów (oczywiście UUID nie mogą być używane, jak w w raportach).
Vineet Reynolds

Zanim masz 50% szans na powielenie, już toniesz. Ktoś wskazał ilość potrzebną do uzyskania 0,0000001% szansy. Wiele baz danych z automatyczną inkrementacją, zaczynając od 1 do ni zwiększając o n za każdym razem, skutecznie rozwiązuje ten sam problem.
Gordon

2
Szanse na uzyskanie duplikatu są
DUŻE, DUŻO

33

Wszystko ma niezerową szansę niepowodzenia. Skoncentrowałbym się na znacznie bardziej prawdopodobnych problemach (tj. Prawie wszystkim, o czym możesz pomyśleć) niż kolizji UUID


Dodano jako odpowiedź na prośbę
Pyrolistics

16

Nacisk na „rozsądnie” lub, jak to ująłeś, „skutecznie”: wystarczająco dobre, jak działa prawdziwy świat. Ilość pracy obliczeniowej związanej z wypełnieniem luki między „praktycznie wyjątkowym” a „naprawdę wyjątkowym” jest ogromna. Wyjątkowość to krzywa z malejącymi zwrotami. W pewnym momencie na tej krzywej znajduje się granica między miejscem, w którym „wystarczająco wyjątkowy” jest nadal dostępny, a następnie BARDZO stromo zakręcamy. Koszt dodania większej wyjątkowości staje się dość duży. Nieskończona wyjątkowość ma nieskończony koszt.

UUID / GUID to, mówiąc relatywnie, obliczeniowo szybki i łatwy sposób generowania identyfikatora, który można rozsądnie założyć jako uniwersalny. Jest to bardzo ważne w wielu systemach, które wymagają integracji danych z wcześniej niepołączonych systemów. Na przykład: jeśli masz system zarządzania treścią, który działa na dwóch różnych platformach, ale w pewnym momencie musisz zaimportować zawartość z jednego systemu do drugiego. Nie chcesz, aby identyfikatory się zmieniały, więc odniesienia między danymi z systemu A pozostają nienaruszone, ale nie chcesz żadnych kolizji z danymi utworzonymi w systemie B. Rozwiązuje to UUID.


Rozwiązanie. Nie bądź leniwy i zaktualizuj referencje. Zrób to dobrze.
Pyrolistic

8
Nie ma to nic wspólnego z lenistwem - jeśli zasada jest taka, że ​​identyfikator elementu jest uważany za stały i niezmienny, to identyfikator się nie zmienia. Więc chcesz, aby identyfikatory były unikalne od samego początku i chcesz to zrobić bez wymagania, aby wszystkie systemy były w jakiś sposób połączone od samego początku.
Michael Burr

Potrzebujesz wtedy kontekstu. Jeśli masz dwie grupy unikalnych identyfikatorów, które mogą kolidować, potrzebujesz wysokiego poziomu kontekstu, aby je rozdzielić
Pyrolistic

23
Lub możesz po prostu zbudować system, aby używać identyfikatorów UUID i wysłać go, sprzedać, zarobić milion dolarów i nigdy nie usłyszeć ani jednej skargi, że zderzyły się dwa identyfikatory, ponieważ tak się nie stanie.
Rex M

16

Tworzenie UUID nigdy nie jest absolutnie konieczne. Wygodne jest jednak posiadanie standardu, w którym każdy użytkownik offline może wygenerować klucz do czegoś z bardzo niskim prawdopodobieństwem kolizji.

Może to pomóc w rozwiązaniu replikacji bazy danych itp.

Użytkownikom online byłoby łatwo generować unikalne klucze do czegoś bez kosztów ogólnych lub możliwości kolizji, ale nie do tego służą identyfikatory UUID.

W każdym razie słowo na temat prawdopodobieństwa kolizji zaczerpnięte z Wikipedii:

Aby spojrzeć na te liczby z odpowiedniej perspektywy, szacuje się, że roczne ryzyko uderzenia meteorytem wynosi jedną szansę na 17 miliardów, co odpowiada prawdopodobieństwu wytworzenia kilkudziesięciu bilionów UUID w ciągu roku i posiadania jednego duplikatu. Innymi słowy, tylko po wygenerowaniu 1 miliarda identyfikatorów UUID na sekundę przez następne 100 lat prawdopodobieństwo powstania tylko jednego duplikatu wyniosłoby około 50%.


4
Proste, nie pozwól użytkownikom offline generować kluczy. Miej przypisane klucze tymczasowe, dopóki system nie przejdzie do trybu online, aby można było wygenerować prawdziwe klucze.
Pyrolistic

Moim zdaniem jest to bardzo pomocna odpowiedź ... miałem zamiar zaoferować jakąś analogię do prawdopodobieństwa, ponieważ wydawało się, że PO nie do końca zrozumiał jego znaczenie, ale wydaje się, że to zrobiłeś.
Noldorin

Po cichu rozumiem, że prawdopodobieństwo jest praktycznie zerowe. Dla mnie użycie UUID jest leniwym projektem i chciałem tylko sprawdzić, czy zawsze możesz tego uniknąć
Pyrolistic

To w porządku, o ile widzisz, że niskie prawdopodobieństwo należy wziąć pod uwagę nawet w najbardziej ekstremalnych okolicznościach, tak jak zakładam teraz.
Noldorin

13

Klasycznym przykładem jest replikacja między dwiema bazami danych.

DB (A) wstawia rekord o ID int 10 i jednocześnie DB (B) tworzy rekord o ID 10. To jest kolizja.

W przypadku UUID tak się nie stanie, ponieważ nie będą one pasować. (prawie na pewno)


1
Ok, w takim razie niech DB A użyje parzystego ID, a DB B nieparzystego ID. Gotowe, brak UUID.
Pyrolistic

2
Przy trzech
bazach danych

20
Jeśli użyjesz wielokrotności 2/3 / cokolwiek, co się stanie, gdy później dodasz nowy serwer do miksu? Musisz skoordynować przełącznik tak, aby używać wielokrotności n + 1 na nowym serwerze i przenieść wszystkie stare serwery do nowego algorytmu, a także musisz wyłączyć wszystko, aby uniknąć kolizji podczas przełącznik algorytmu. Lub ... możesz po prostu użyć identyfikatorów UUID, takich jak KAŻDY INNY.
Bob Aman

3
Jest jeszcze gorzej, bo jak odróżnić wielokrotność 2 od wielokrotności 4? Albo wielokrotność 3 a wielokrotność 6? W rzeczywistości musiałbyś trzymać się wielokrotności liczb pierwszych. Blech! Po prostu użyj UUID, to działa. Microsoft, Apple i niezliczone inne firmy polegają na nich i im ufają.
sidewinderguy

2
@sidewinderguy, zaufany identyfikator GUID! :)
Ron Klein

13

Istnieje również niezerowe prawdopodobieństwo, że każda cząstka w twoim ciele jednocześnie przejdzie przez krzesło, na którym siedzisz, i nagle znajdziesz się na podłodze.

Martwisz się o to?


7
Oczywiście, że nie, nie mogę tego kontrolować, ale projekty, które mogę.
Pyrolistic

4
@Pirolistic Czy to naprawdę, mam na myśli NAPRAWDĘ powód, dla którego się tym nie martwisz? Więc jesteś dość dziwny. Co więcej, nie masz racji. Możesz to kontrolować. Zyskując kilka kilogramów znacznie zmniejszasz prawdopodobieństwo takiego zdarzenia. Czy uważasz, że powinieneś przytyć? :-)
Veky

8

Mam schemat unikania identyfikatorów UUID. Skonfiguruj gdzieś serwer i miej go tak, że za każdym razem, gdy jakiś program potrzebuje uniwersalnego unikalnego identyfikatora, kontaktuje się z tym serwerem, a on go wydaje. Prosty!

Tyle że są z tym pewne praktyczne problemy, nawet jeśli ignorujemy jawną złośliwość. W szczególności ten serwer może ulec awarii lub stać się niedostępny z części Internetu. Radzenie sobie z awarią serwera wymaga replikacji, a to jest bardzo trudne do wykonania (patrz literatura na temat algorytmu Paxos, aby dowiedzieć się, dlaczego budowanie konsensusu jest niezręczne) i jest również dość powolne. Co więcej, jeśli wszystkie serwery są nieosiągalne z określonej części sieci, żaden z klientów podłączonych do tej podsieci nie będzie w stanie nic zrobić, ponieważ wszyscy będą czekać na nowe identyfikatory.

Więc ... użyj prostego algorytmu probabilistycznego, aby wygenerować je, które prawdopodobnie nie zawiodą podczas życia Ziemi, lub (sfinansuj i) zbuduj główną infrastrukturę, która będzie wdrożeniem PITA i będzie miała częste awarie. Wiem, na który wybrałbym.


2
Właściwie, celem wymyślenia UUID było uniknięcie twojego podejścia. Jeśli zbadasz historię identyfikatorów UUID, zobaczysz, że wywodzi się ona z najwcześniejszych eksperymentów dotyczących tworzenia wyrafinowanych i znaczących sieci komputerów. Wiedzieli, że sieci są z natury zawodne i skomplikowane. Identyfikatory UUID były odpowiedzią na pytanie, jak koordynować dane między komputerami, kiedy wiedziałeś, że nie mogą być w ciągłej komunikacji.
Basil Bourque

7
@BasilBourque W pierwszym akapicie użyłem sarkazmu, na wypadek, gdyby nie było to oczywiste.
Donal Fellows

5

nie rozumiem wszystkiego o prawdopodobieństwie kolizji. Nie obchodzi mnie kolizja. Ale zależy mi na wydajności.

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

Identyfikatory UUID powodują katastrofę wydajności w przypadku bardzo dużych tabel. (200 tys. Wierszy nie oznacza „bardzo dużych”).

Twój # 3 jest naprawdę zły, gdy CHARCTER SET to utf8 - CHAR (36) zajmuje 108 bajtów!

Identyfikatory UUID (GUID) są bardzo „losowe”. Używanie ich jako klucza UNIQUE lub PRIMARY w przypadku dużych tabel jest bardzo nieefektywne. Wynika to z konieczności przeskakiwania tabeli / indeksu za każdym razem, gdy WSTAWISZ nowy UUID lub WYBIERZ przez UUID. Gdy tabela / indeks jest zbyt duży, aby zmieścić się w pamięci podręcznej (patrz innodb_buffer_pool_size, który musi być mniejszy niż pamięć RAM, zwykle 70%), „następny” UUID może nie zostać zapisany w pamięci podręcznej, stąd powolne uderzenie w dysk. Gdy tabela / indeks jest 20 razy większy niż pamięć podręczna, tylko 1/20 (5%) trafień jest buforowanych - jesteś związany we / wy.

Dlatego nie używaj identyfikatorów UUID, chyba że jeden z nich

masz „małe” tabele lub naprawdę potrzebujesz ich do generowania unikalnych identyfikatorów z różnych miejsc (i nie znalazłeś innego sposobu, aby to zrobić). Więcej o UUID: http://mysql.rjweb.org/doc.php/uuid (Zawiera funkcje do konwersji między standardowymi 36-znakowymi UUID i BINARY (16).)

Posiadanie zarówno UNIKALNEGO AUTO_INCREMENT, jak i UNIKALNEGO UUID w tej samej tabeli jest marnotrawstwem.

Gdy wystąpi INSERT, wszystkie klucze unikalne / podstawowe muszą zostać sprawdzone pod kątem duplikatów. Każdy klucz unikatowy jest wystarczający, aby InnoDB wymagał posiadania klucza podstawowego. BINARY (16) (16 bajtów) jest nieco nieporęczny (argument przeciwko uczynieniu go PK), ale nie jest taki zły. Wielkość ma znaczenie, gdy masz klucze dodatkowe. InnoDB po cichu przypina PK na końcu każdego klucza dodatkowego. Główna lekcja dotyczy zminimalizowania liczby kluczy drugorzędnych, szczególnie w przypadku bardzo dużych tabel. Dla porównania: INT UNSIGNED to 4 bajty z zakresem 0..4 miliardów. BIGINT ma 8 bajtów.


4

Jeśli spojrzysz tylko na alternatywy, np. Prostą aplikację bazodanową, aby za każdym razem przed utworzeniem nowego obiektu musieć przesyłać zapytania do bazy danych, szybko przekonasz się, że użycie UUID może skutecznie zredukować złożoność systemu. Granted - jeśli używasz kluczy int, są 32-bitowe, które będą przechowywać w jednej czwartej 128-bitowego UUID. To prawda - algorytmy generujące UUID zajmują więcej mocy obliczeniowej niż zwykłe zwiększanie liczby. Ale kogo to obchodzi? Narzut związany z zarządzaniem „organem” w celu przypisania unikalnych numerów łatwo przeważa o rzędy wielkości, w zależności od zamierzonego obszaru identyfikatora unikalności.


3

Na UUID == leniwy projekt

Nie zgadzam się, że chodzi o wybieranie twoich walk. Jeśli duplikat UUID jest statystycznie niemożliwy, a matematyka została udowodniona, to po co się martwić? Poświęcanie czasu na projektowanie wokół małego systemu generującego N UUID jest niepraktyczne, zawsze istnieje tuzin innych sposobów na ulepszenie systemu.


1

W mojej ostatniej pracy otrzymywaliśmy od stron trzecich przedmioty, które były jednoznacznie identyfikowane za pomocą UUID. Umieściłem w tabeli wyszukiwania UUID-> długie liczby całkowite i użyłem długich liczb całkowitych jako moich kluczy podstawowych, ponieważ w ten sposób było o wiele szybciej.


Jasne, strona trzecia zmuszająca Cię do używania UUID to kolejna kwestia, której nie chcę się zajmować. Zakładając, że masz kontrolę nad używaniem UUID, czy nie.
Pyrolistic

Cóż, „długa liczba całkowita” (128 bitów) jest w rzeczywistości tym, czym jest UUID. Jest po prostu pokazany jako sznurek do spożycia przez ludzi. Czasami może być przesyłany w ten sposób, ale w przypadku przechowywania i indeksowania będzie z pewnością szybszy w postaci liczb całkowitych, jak znalazłeś.
Nicole

1

Korzystając z algorytmu wersji 1 wydaje się, że kolizja jest niemożliwa pod warunkiem, że mniej niż 10 UUID na milisekundę jest generowanych z tego samego adresu MAC

Koncepcyjnie pierwotny (wersja 1) schemat generowania identyfikatorów UUID polegał na konkatenacji wersji UUID z adresem MAC komputera, który generuje UUID, oraz z liczbą 100-nanosekundowych interwałów od czasu przyjęcia kalendarza gregoriańskiego na Zachodzie . W praktyce rzeczywisty algorytm jest bardziej skomplikowany. System ten był krytykowany, ponieważ nie jest wystarczająco „nieprzejrzysty”; ujawnia zarówno tożsamość komputera, który wygenerował UUID, jak i czas, w którym to zrobił.

Niech ktoś mnie poprawi, jeśli źle zinterpretowałem, jak to działa


Istnieje wiele wersji, a wiele systemów oprogramowania (na przykład Java) nie może używać wersji 1, ponieważ nie ma ona czystego sposobu Java na dostęp do adresu mac.
Pyrolistic

Odnośnie niezdolności Javy do uzyskania adresu MAC: Nie do końca prawda. Istnieją na to obejścia. Możesz ręcznie ustawić adres MAC używany przez generator za pomocą pliku konfiguracyjnego. Możesz również wywołać ifconfig i przeanalizować dane wyjściowe. Generator Ruby UUID, który napisałem, wykorzystuje oba podejścia.
Bob Aman

Ponadto, jak wspomniałem w mojej odpowiedzi, jeśli nie możesz uzyskać adresu MAC dla UUID wersji 1, użyj zamiast tego 6 losowych bajtów, zgodnie z sekcją 4.5 dokumentu RFC 4122. Więc nawet jeśli nie chcesz używać żadnego z dwóch obejść dla języka Java, nadal można wygenerować prawidłowy UUID wersji 1.
Bob Aman

Identyfikatory GUID MS to po prostu liczby losowe. Nie mają już żadnej części MAC, ponieważ umożliwiło to odtworzenie adresu MAC serwera (który okazał się bardzo niebezpieczny).
Stefan Steiger,

1

Do tych, którzy twierdzą, że identyfikatory UUID są złym projektem, ponieważ mogą (z jakimś śmiesznie małym prawdopodobieństwem) kolidować, podczas gdy klucze wygenerowane przez bazę danych nie będą ... znacie możliwość wystąpienia błędu ludzkiego powodującego kolizję kluczy wygenerowanych -przeznaczona potrzeba jest DUŻO DUŻO większa niż prawdopodobieństwo kolizji UUID4. Wiemy , że jeśli baza danych zostanie odtworzona, identyfikatory ponownie zaczną się od 1, a ilu z nas musiało odtworzyć tabelę, gdy byliśmy pewni, że nigdy nie będziemy tego potrzebować? Postawiłbym pieniądze na bezpieczeństwo UUID, gdy coś zacznie się nie udać z nieznanymi-niewiadomymi.


0

Oprócz przypadków, w których musisz użyć cudzego API, które wymaga identyfikatora UUID, oczywiście zawsze istnieje inne rozwiązanie. Ale czy te alternatywy rozwiążą wszystkie problemy, które powodują identyfikatory UUID? Czy w końcu dodasz więcej warstw hacków, z których każda ma rozwiązać inny problem, podczas gdy mógłbyś rozwiązać je wszystkie naraz?

Tak, teoretycznie istnieje możliwość kolizji identyfikatorów UUID. Jak zauważyli inni, jest to absurdalnie nieprawdopodobne do tego stopnia, że ​​po prostu nie warto się nad tym zastanawiać. To się nigdy nie zdarzyło i najprawdopodobniej nigdy nie będzie. Zapomnij o tym.

Najbardziej „oczywistym” sposobem uniknięcia kolizji jest pozwolenie pojedynczemu serwerowi na generowanie unikalnych identyfikatorów dla każdej wkładki, co oczywiście stwarza poważne problemy z wydajnością i nie rozwiązuje w ogóle problemu generowania offline. Ups.

Innym „oczywistym” rozwiązaniem jest centralny organ, który z wyprzedzeniem rozdaje bloki unikalnych numerów, co jest zasadniczo tym, co robi UUID V1, wykorzystując adres MAC maszyny generującej (za pośrednictwem IEEE OUI). Jednak zduplikowane adresy MAC zdarzają się, ponieważ każdy organ centralny w końcu spieprzy, więc w praktyce jest to znacznie bardziej prawdopodobne niż kolizja UUID V4. Ups.

Najlepszym argumentem przeciwko używaniu identyfikatorów UUID jest to, że są one „zbyt duże”, ale (znacznie) mniejszy schemat nieuchronnie nie rozwiąże najciekawszych problemów; Rozmiar identyfikatorów UUID jest nieodłącznym efektem ubocznym ich przydatności w rozwiązywaniu tych właśnie problemów.

Możliwe, że Twój problem nie jest wystarczająco duży, aby potrzebować tego, co oferują identyfikatory UUID, w takim przypadku możesz użyć czegoś innego. Ale jeśli twój problem nieoczekiwanie narasta (a większość tak się dzieje), później zmienisz się na inne - i skopiesz się za to, że ich nie używasz. Po co projektować pod kątem porażki, skoro równie łatwo jest projektować pod kątem sukcesu?


-10

Identyfikatory UUID obejmują wszystkie złe praktyki kodowania związane ze zmiennymi globalnymi, tylko gorzej, ponieważ są to zmienne superglobalne, które można rozłożyć na różne elementy zestawu.

Niedawno natrafiłem na taki problem z wymianą drukarki na dokładny model zastępczy i stwierdziłem, że żadne oprogramowanie klienckie nie będzie działać.


2
Cieszę się, że żyjemy w społeczeństwie, które nadal koncentruje się na faktach, a nie na przypadkowych opiniach, w przeciwnym razie wszyscy z przepełnienia stosu straciliby pracę. :)
Makarand
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.