Probabilidad de colisión utilizando los bits más significativos de un UUID en Java

Question

Si estoy usando Long uuid = UUID.randomUUID (). getMostSignificantBits () qué tan probable es que se produzca una colisión. Corta los bits menos significativos, por lo que existe la posibilidad de que se encuentre con una colisión, ¿verdad?

Answer 1

Según la documentación , la El método estático UUID.randomUUID () genera un UUID de tipo 4.

Esto significa que se utilizan seis bits para cierta información de tipo y los 122 bits restantes se asignan aleatoriamente.

Los seis bits no aleatorios se distribuyen con cuatro en la mitad más significativa del UUID y dos en la mitad menos significativa. Entonces, la mitad más significativa de su UUID contiene 60 bits de aleatoriedad, lo que significa que, en promedio, necesita generar 2 ^ 30 UUID para obtener una colisión (en comparación con 2 ^ 61 para el UUID completo).

Entonces diría que estás bastante seguro. Sin embargo, tenga en cuenta que esto no es absolutamente cierto para otros tipos de UUID, como menciona Carl Seleborg.

Por cierto, estaría un poco mejor utilizando la mitad menos significativa del UUID (o simplemente generando un largo aleatorio usando SecureRandom).

Answer 2

Raymond Chen tiene una excelente publicación de blog sobre esto:

Los GUID son globalmente únicos, pero las subcadenas de GUID no lo son

Answer 3

Creo que este es el mejor ejemplo para usar randomUUID:

http://www.javapractices.com/topic/TopicAction.do? Id = 56

Answer 4

Es mejor que solo genere un valor largo aleatorio, luego todos los bits son aleatorios. En Java 6, el nuevo Random () usa System.nanoTime () más un contador como semilla.

Hay diferentes niveles de unicidad.

Si necesita unicidad en muchas máquinas, podría tener una tabla de base de datos central para asignar identificadores únicos, o incluso lotes de identificadores únicos.

Si solo necesita tener unicidad en una aplicación, puede tener un contador (o un contador que comience desde currentTimeMillis () * 1000 o nanoTime () según sus requisitos)

Answer 5

Use Time YYYYDDDD (año + día del año) como prefijo. Esto disminuye la fragmentación de la base de datos en tablas e índices. Este método devuelve byte [40] . Lo utilicé en un entorno híbrido donde el SID de Active Directory ( varbinary (85) ) es la clave para los usuarios de LDAP y se usa una aplicación ID generada automáticamente para usuarios que no son LDAP. Además, la gran cantidad de transacciones por día en las tablas transaccionales (industria bancaria) no puede usar los tipos estándar Int para Keys

private static final DecimalFormat timeFormat4 = new DecimalFormat("0000;0000");

public static byte[] getSidWithCalendar() {
    Calendar cal = Calendar.getInstance();
    String val = String.valueOf(cal.get(Calendar.YEAR));
    val += timeFormat4.format(cal.get(Calendar.DAY_OF_YEAR));
    val += UUID.randomUUID().toString().replaceAll("-", "");
    return val.getBytes();
}