A probabilidade de colisão usando bits mais significativos de um UUID em Java

Question

Se eu estou usando Long uuid = UUID.randomUUID().getMostSignificantBits() qual é a probabilidade de obter uma colisão.Ele corta os bits menos significativos, portanto, há uma possibilidade de que você executar em uma colisão, certo?

Answer 1

De acordo com a a documentação, o método estático UUID.randomUUID() gera um tipo 4 UUID.

Isso significa que seis bits são usados para algum tipo de informação e os restantes 122 bits são atribuídos aleatoriamente.

Seis não-aleatória de bits são distribuídos com quatro mais significativos metade do UUID e dois a menos significativo metade.Por isso, a mais significativa metade de seu UUID contém 60 bits de aleatoriedade, o que significa que, em média, precisa gerar 2^30 Uuid para obter uma colisão (comparado a 2^61 para o completo UUID).

Então, eu diria que você está bastante seguro.Note, no entanto que isso não é verdade para outros tipos de Uuid, como Carl Seleborg menciona.

Aliás, você poderia ser um pouco melhor usando o menos significativo metade do UUID (ou apenas a geração aleatória de utilização longa SecureRandom).

Answer 2

Raymond Chen tem um post realmente excelente no blog sobre isso:

Guids são globalmente únicos, mas substrings de guids não são

Answer 3

Eu acho que este é o melhor exemplo para usar randomuuid:

http://www.javapractices.com/topic/topicaction.do?id=56

Answer 4

É melhor você apenas gerar um valor longo aleatório, então todos os bits são aleatórios. Em Java 6, o novo aleatório () usa o sistema.nanotime () mais um contador como semente.

Existem diferentes níveis de exclusividade.

Se você precisar de singularidade em muitas máquinas, poderá ter uma tabela central de banco de dados para alocar IDs exclusivos ou até lotes de IDs exclusivos.

Se você só precisa ter singularidade em um aplicativo, poderá apenas ter um contador (ou um contador que começa a partir do currentTimEmillis ()*1000 ou nanotime (), dependendo dos seus requisitos)

Answer 5

Usar o tempo YYYYDDDD (Ano + dia do ano) como prefixo. Isso diminui a fragmentação do banco de dados em tabelas e índices. Este método retorna byte[40]. Eu o usei em um ambiente híbrido onde o Active Directory SID (varbinary(85)) é a chave para os usuários do LDAP e um ID gerado automaticamente é usado para usuários que não são do LLDAP. Além disso, o grande número de transações por dia em tabelas transacionais (indústria bancária) não pode usar o padrão Int tipos para chaves

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();
}