O problema

Estou procurando feedback sobre essa exploração de umalternativa localmente única para GUIDs, com os seguintes requisitos:

Tem uma chance muito baixa de colisões (a ponto de preferirmos colidir uma vez por ano do que realizar verificações)Não vazasensível informações, como quantos itens existemPossui alto desempenho em um banco de dados SQLÉ cópia / colável para consulta manual (como seqüência de caracteres e resultado da consulta)É utilizável como um componente URI sem codificação

Para atender aos requisitos, decidi sobre a forma de umNúmero inteiro não assinado de 64 bits. É fácil na CPU, agradável e pequeno para uso da chave primária, legível por meio de humanos, somente dígitos e fácil de copiar / colar ao consultar manualmente. (Como um contra-exemplo, os BLOBs dificultam severamente a consulta manual na maioria dos bancos de dados SQL.)

Além disso, Perconademonstra estevalores monotonicamente crescentes ter um desempenho muito melhor como chaves primárias, principalmente na velocidade de inserção, portanto, essa é uma característica a ser buscada.

Estrutura proposta

Da esquerda para a direita, os bits mais significativos estão à esquerda

46 bits.Registro de data e hora. Tempo Unix em milissegundos. (Pelo menos em C #, o tempo de menos de milissegundos não está prontamente disponível.) Isso durará até algum momento do ano de 4199. Ele nos fornece valores crescentemente monotônicos.8 bits.Parte do IP local. O último componente do endereço IP interno da máquina, da interface de rede mais rápida disponível. Deve ser LAN Ethernet para a maioria dos servidores.10 bits.Uniquefier. Um contador estático que é incrementado (intertravado) em uso, com wrap-around.

Colisões

Existe uma chance de colisão de 1/1024 (~ 0,1%) sempre que:

Dois sistemas compartilham o mesmo último componente de endereço IPe faça uma chamada no mesmo milissegundo.Isso pode ser completamente evitado.O relógio de um sistema é retornadoe faz uma chamada no mesmo milissegundo de uma chamada antes da alteração da hora.Essa deve ser uma situação pouco frequente que parece estar dentro dos requisitos.

Limitações

Curiosamente, parece que estamos cumprindo os requisitos (o número 2 é desonesto). Vamos dar uma olhada em algumas das limitações.

Os endereços IP locais dos servidores devem ser cuidadosamente mantidos - mesmo entre diferentes data centers, se aplicável.Não podemos suportar mais de 255 servidores - possivelmente menos, se existirem outras restrições nos IPs.Vazamos informações sobre quais identificadores foram criados pelo mesmo servidor. Porém, acredito que este seja o caso de muitas implementações de GUID.É possível obter informações sobre volumes de tráfego, verificando incrementos de contador entre as próprias solicitações de um usuário. A eficácia é diminuída pelo fato de o contador ser usado para vários tipos de dados, aumentando rapidamente e de uma maneira difícil de atribuir a qualquer tipo específico de dados.Identificadores são muito mais fáceis de adivinhar do que aqueles que têm muita aleatoriedade. Um ataque de força bruta precisaria de cerca de 512 chamadas (número único) por tentativa de milissegundo. Idealmente, esse ataque não produz nada, ou seja, o sistema relata "não autorizado", independentemente de o identificador ser inexistente ou não pertencer ao usuário e ser resistente a ataques de tempo. Realisticamente, vamos supor que um invasor dedicado encontre um vazamento.

Considerações

As limitações 1 e 2 devem simplesmente se encaixar na empresa.

A limitação nº 3 parece ser considerada aceitável nas implementações existentes do GUID e é com a qual estou disposto a conviver.

A limitação nº 4 é complicada. Quão sensível é essa informação? "Então, fazemos 10 mil inserções por minuto, em um número desconhecido de tabelas". Os volumes relativos concedem mais informações: "Entre 08: 00-09: 00, há duas vezes mais atividade do que uma hora antes." Ainda assim, isso geralmente será de conhecimento comum em um determinado campo. Picos inesperados podem vazar mais algumas informações. "Então o sistema trabalha duro às 03:00 da manhã." Quão ruim é tudo isso? A julgar pelo número de empresas que expõem identificadores de auto incremento, poderíamos dizer que é uma melhoria mais frequentemente do que não ... Mas pode ser uma quebra de negócio.

Poderíamos usar bits aleatórios (criptografados) como os únicos a lidar com a limitação nº 4, mas isso introduziria uma terceira oportunidade de colisão: sempre que o sistema gerar vários identificadores em um milissegundo. O paradoxo do aniversário é particularmente problemático lá.

Poderíamos liberar 2 bits se permitirmos que o carimbo de data e hora já esteja disponível em 2527. Egoísta e insensível às gerações futuras, ou arrogante ao assumir que nosso código seria usado por mais tempo? :-)

O quê mais?

Congratulo-me com o seu feedback, melhorias, idéias, limitações que eu perdi! Como resolveria este problema?