Quando dovrei usare uuid.uuid1 () vs. uuid.uuid4 () in Python?

Comprendo le differenze tra i due dai documenti.

uuid1():
Genera un UUID da un ID host, un numero di sequenza e l'ora corrente

uuid4():
Genera un UUID casuale.

Quindi uuid1utilizza le informazioni macchina / sequenza / tempo per generare un UUID. Quali sono i pro e i contro dell'utilizzo di ciascuno?

So che uuid1()può avere problemi di privacy, dal momento che si basa su informazioni sulla macchina. Mi chiedo se c'è qualcosa di più sottile nella scelta dell'uno o dell'altro. Uso solo uuid4()ora, dal momento che è un UUID completamente casuale. Ma mi chiedo se dovrei usare uuid1per ridurre il rischio di collisioni.

Fondamentalmente, sto cercando i consigli delle persone per le migliori pratiche sull'uso dell'uno contro l'altro. Grazie!

uuid1()è garantito che non si producono collisioni (partendo dal presupposto che non ne crei troppe contemporaneamente). Non lo userei se è importante che non ci sia alcuna connessione tra uuidil computer e, poiché l'indirizzo mac viene utilizzato per renderlo unico su tutti i computer.

È possibile creare duplicati creando più di 2 ¹⁴ uuid1 in meno di 100 ns, ma questo non è un problema per la maggior parte dei casi d'uso.

uuid4()genera, come hai detto, un UUID casuale. La possibilità di una collisione è davvero molto, molto piccola. Abbastanza piccolo, che non dovresti preoccupartene. Il problema è che un cattivo generatore di numeri casuali aumenta le probabilità di avere collisioni.

Questa eccellente risposta di Bob Aman lo riassume bene. (Consiglio di leggere l'intera risposta.)

Francamente, in un unico spazio di applicazione senza attori malvagi, l'estinzione di tutta la vita sulla Terra avverrà molto prima che tu abbia una collisione, anche su un UUID versione 4, anche se stai generando un bel po 'di UUID al secondo.

Un esempio quando si può prendere in considerazione uuid1(), piuttosto che uuid4()è quando UUID vengono prodotti su macchine separate , ad esempio quando più transazioni online sono processo su diverse macchine per scopi ridimensionamento.

In una situazione del genere, ad esempio, i rischi di collisioni dovuti a scelte errate nel modo in cui vengono inizializzati i generatori di numeri pseudo-casuali e anche il numero potenzialmente più elevato di UUID prodotti rende più probabile la possibilità di creare ID duplicati.

Un altro interesse di uuid1(), in quel caso, è che la macchina su cui inizialmente è stato prodotto ciascun GUID è implicitamente registrata (nella parte "nodo" di UUID). Questa e le informazioni sul tempo possono essere utili se non altro per il debug.

Il mio team ha appena avuto problemi con UUID1 per uno script di aggiornamento del database in cui abbiamo generato circa 120k UUID in un paio di minuti. La collisione UUID ha portato alla violazione di un vincolo chiave primaria.

Abbiamo aggiornato centinaia di server ma nelle nostre istanze Amazon EC2 abbiamo riscontrato questo problema alcune volte. Sospetto che la risoluzione dell'orologio sia scadente e il passaggio a UUID4 l'ha risolto per noi.

Una cosa da notare quando si utilizza uuid1, se si utilizza la chiamata predefinita (senza fornire il clock_seqparametro) si ha la possibilità di incorrere in collisioni: si ha solo 14 bit di casualità (la generazione di 18 voci in 100 ns offre all'incirca l'1% di probabilità di una collisione. paradosso / attacco di compleanno). Il problema non si verificherà mai nella maggior parte dei casi d'uso, ma su una macchina virtuale con una bassa risoluzione dell'orologio ti morde.

Forse qualcosa che non è stato menzionato è quello della località.

Un indirizzo MAC o un ordinamento basato sul tempo (UUID1) può offrire maggiori prestazioni del database, poiché è meno lavoro per ordinare i numeri più vicini di quelli distribuiti in modo casuale (UUID4) (vedere qui ).

Un secondo problema correlato è che l'utilizzo di UUID1 può essere utile nel debug, anche se i dati di origine vengono persi o non vengono archiviati in modo esplicito (questo è ovviamente in conflitto con il problema di privacy menzionato dall'OP).

Oltre alla risposta accettata, esiste una terza opzione che può essere utile in alcuni casi:

v1 con MAC casuale ("v1mc")

È possibile creare un ibrido tra v1 e v4 generando deliberatamente UUID v1 con un indirizzo MAC di trasmissione casuale (ciò è consentito dalle specifiche v1). L'UUID v1 risultante dipende dal tempo (come il normale v1), ma manca di tutte le informazioni specifiche dell'host (come v4). È anche molto più vicino a v4 nella sua resistenza alle collisioni: v1mc = 60 bit di tempo + 61 bit casuali = 121 bit unici; v4 = 122 bit casuali.

Il primo posto che ho riscontrato è stata la funzione uuid_generate_v1mc () di Postgres . Da allora ho usato il seguente equivalente di Python:

from os import urandom
from uuid import uuid1
_int_from_bytes = int.from_bytes  # py3 only

def uuid1mc():
    # NOTE: The constant here is required by the UUIDv1 spec...
    return uuid1(_int_from_bytes(urandom(6), "big") | 0x010000000000)

(nota: ho una versione più lunga + più veloce che crea direttamente l'oggetto UUID; può pubblicare se qualcuno lo desidera)

In caso di GRANDI volumi di chiamate / secondo, ciò può esaurire la casualità del sistema. Si potrebbe utilizzare lo stdlib randommodulo invece (sarà probabilmente anche più veloce). Ma ATTENZIONE: bastano poche centinaia di UUID prima che un attaccante possa determinare lo stato di RNG e quindi prevedere parzialmente gli UUID futuri.

import random
from uuid import uuid1

def uuid1mc_insecure():
    return uuid1(random.getrandbits(48) | 0x010000000000)