El problema

Estoy buscando comentarios sobre esta exploración de unalternativa localmente única para GUID, con los siguientes requisitos:

Tiene muy pocas posibilidades de colisiones (hasta el punto de que preferimos colisionar una vez al año que realizar controles)No goteasensible información, como cuántos elementos existenTiene alto rendimiento en una base de datos SQLEs copiable / pegable para consultas manuales (como cadena de consulta y resultado de consulta)Se puede usar como un componente URI sin codificación

Para cumplir con los requisitos, he decidido la forma de unEntero sin signo de 64 bits. Es fácil en la CPU, agradable y pequeño para el uso de la clave principal, legible para humanos, solo dígitos y fácil de copiar / pegar cuando se realiza una consulta a mano. (Como contraejemplo, los BLOB obstaculizan severamente las consultas manuales en la mayoría de las bases de datos SQL).

Además, Perconademuestra esevalores monotónicamente crecientes funcionan mucho mejor como claves primarias, particularmente en la velocidad de inserción, por lo que este es un rasgo que se debe buscar

Estructura propuesta

De izquierda a derecha, los bits más significativos están a la izquierda.

46 bits.Marca de tiempo. Tiempo de Unix en milisegundos. (Al menos en C #, el tiempo por debajo de milisegundos no está disponible fácilmente). Esto durará hasta algún lugar en el año 4199. Nos da valores monotónicamente crecientes.8 bitsParte de IP local. El último componente de la dirección IP interna de la máquina, de la interfaz de red más rápida disponible. Debe ser LAN Ethernet para la mayoría de los servidores.10 bitsUniquefier. Un contador estático que se incrementa (enclava) en uso, con ajuste.

Colisiones

Existe una posibilidad de colisión de 1/1024 (~ 0.1%) siempre que:

Dos sistemas comparten el mismo último componente de dirección IPy hacer una llamada en el mismo milisegundo.Esto se puede evitar por completo.El reloj de un sistema está retrasadoy realiza una llamada en el mismo milisegundo de una llamada antes del cambio de hora.Esta debería ser una situación muy poco frecuente que parece estar dentro de los requisitos.

Limitaciones

Curiosamente, parece que estamos cumpliendo los requisitos (el # 2 es dudoso). Echemos un vistazo a algunas de las limitaciones.

Las direcciones IP locales de los servidores deben mantenerse cuidadosamente, incluso entre diferentes centros de datos, si corresponde.No podemos admitir más de 255 servidores, posiblemente menos, si existen otras restricciones en las IP.Filtramos información sobre qué identificadores fueron creados por el mismo servidor. Sin embargo, creo que este es el caso con muchas implementaciones de GUID también.Se puede obtener información sobre los volúmenes de tráfico, comprobando los incrementos de contador entre las propias solicitudes de un usuario. La efectividad se ve disminuida por el hecho de que el contador se usa para varios tipos de datos, aumentando rápidamente y de una manera que es difícil de atribuir a cualquier tipo particular de datos.Los identificadores son mucho más adivinables que los que tienen mucha aleatoriedad. Un ataque de fuerza bruta necesitaría aproximadamente 512 llamadas (unicofier) por intento de milisegundo. Idealmente, este ataque no produce nada, es decir, el sistema informa "no autorizado" independientemente de si el identificador no existe o no pertenece al usuario, y es resistente a los ataques de sincronización. Siendo realistas, supongamos que un atacante dedicado encontrará una fuga.

Consideraciones

Las limitaciones n. ° 1 y n. ° 2 simplemente deben ajustarse a la empresa.

La limitación n. ° 3 parece considerarse aceptable en las implementaciones de GUID existentes, y es una con la que estoy dispuesto a vivir.

La limitación n. ° 4 es complicada. ¿Cuán sensible es esta información? "Así que hacemos unos insertos de 10K por minuto, en un número desconocido de tablas". Los volúmenes relativos otorgan más información: "Entre las 08: 00-09: 00 hay el doble de actividad que una hora antes". Aún así, esto generalmente será de conocimiento común en un campo determinado. Los picos inesperados pueden filtrar más información. "Así que el sistema trabaja duro a las 03:00 de la mañana". ¿Qué tan malo es todo esto? A juzgar por la cantidad de compañías que exponen identificadores de incremento automático, podríamos decir que es una mejora más a menudo que no ... Pero podría ser un factor decisivo.

Podríamos usar bits aleatorios (criptográficos) como el pez único para lidiar con la limitación # 4, pero eso introduciría una tercera oportunidad de colisión: siempre que el sistema genere múltiples identificadores en un milisegundo. La paradoja del cumpleaños es particularmente problemática allí.

Podríamos liberar 2 bits si permitimos que la marca de tiempo se ajuste en 2527 ya. ¿Egoísta e insensible para las generaciones futuras, o arrogante para asumir que nuestro código se usaría por más tiempo? :-)

¿Qué más?

Agradezco sus comentarios, mejoras, ideas, limitaciones que me he perdido! Como resolverías este problema?