Después de leer todas sus preguntas ( ¿la restricción única hace que los hashes sean inútiles? , 512 bit hash vs 4 128bit hash y compresión de texto URL (sin acortar ) y almacenar en mysql ), entendí que tu problema es más o menos el siguiente:
¿Es eso?
Los siguientes puntos son importantes:¿Cómo es el formato de la URL que vas a guardar? ¿Necesitará volver a leer la URL o simplemente actualizar la información al respecto, pero nunca buscar en URL parciales, etc.?
Asumiendo URL ="http://www.somesite.com.tv/images/picture01 .jpg " y que desea almacenar todo, incluido el nombre del archivo. Si es diferente, proporcione más detalles o corrija las suposiciones de mi respuesta .
-
Si puede ahorrar espacio reemplazando algún grupo de caracteres en la URL. No todos los caracteres ASCII son válidos en una URL, como puede ver aquí:RFC1738 , por lo que puede usarlos para representar (y comprimir) la URL. Por ejemplo:usar el carácter 0x81 para representar "http://" puede ahorrarle 6 caracteres, 0x82 para representar ".jpg" puede ahorrarle otros 3 bytes, etc.
-
Algunas palabras pueden ser muy comunes (como "imagen", "imagen", "video", "usuario"). Si elige usar los caracteres 0x90 hasta 0x9f + cualquier otro carácter (por ejemplo, 0x90 0x01, 0x90 0x02, 0x90 0xfa) para codificar tales palabras, puede tener 16 * 256 =4096 "entradas de diccionario" para codificar las palabras más utilizadas. Usará 2 bytes para representar de 4 a 8 caracteres.
Editar: como puede leer en el RFC mencionado anteriormente, en la URL solo puede tener los caracteres ASCII imprimibles. Esto significa que solo se deben usar los caracteres 0x20 a 0x7F, con algunas observaciones hechas en el RFC. Por lo tanto, cualquier carácter después de 0x80 (notación hexadecimal, sería el carácter 128 decimal en la tabla ASCII) no debe usarse. Entonces, si puede elegir un carácter (digamos el 0x90) para que sea un indicador para indicar "el siguiente byte es una indicación en el diccionario, el índice que usaré". Un carácter (0x90) * 256 caracteres (0x00 hasta 0xFF) =256 entradas en el diccionario. Pero también puede optar por utilizar los caracteres 0x90 a 0x9f (o 144 a 159 en decimal) para indicar que son una bandera para el diccionario, lo que le brinda 16 * 256 posibilidades...
Estos 2 métodos pueden ahorrarle mucho espacio en su base de datos y son reversibles, sin necesidad de preocuparse por colisiones, etc. Simplemente creará un diccionario en su aplicación e irá a codificar/decodificar URL usándolo, muy rápido, haciendo tu base de datos mucho más ligera.
Como ya tiene más de 50 millones de URL, puede generar estadísticas basadas en ellas para generar un mejor diccionario.
Uso de hashes :Los hashes, en este caso, son una compensación entre tamaño y seguridad. ¿Qué tan malo será si chocas? Y en este caso puedes usar la paradoja del cumpleaños para ayudarte.
Lea el artículo para comprender el problema:si todas las entradas (posibles caracteres en la URL) fueran equivalentes, podría estimar la probabilidad de una colisión. Y podría calcular lo contrario:dada su probabilidad de colisión aceptable y su número de archivos, ¿qué tan amplio debería ser su rango? Y dado que su rango está exactamente relacionado con la cantidad de bits generados por la función hash...
Editar: si tiene una función hash que le da 128 bits, tendrá 2^128 resultados posibles. Entonces, tu "rango" en la paradoja del cumpleaños es 2^128:es como si tu año tuviera 2^128 días, en lugar de 365. Entonces, calculas las probabilidades de colisión ("dos archivos haber nacido en el mismo día, con un año que tienen 2^128 días en lugar de 365 días). Si elige usar un hash que le dé 512 bits, su rango iría de 0 a 2^512...
Y, de nuevo, tenga en cuenta el RFC:no todos los bytes (256 caracteres) son válidos en el mundo de Internet/URL. Por lo tanto, la probabilidad de colisiones disminuye. Mejor para ti :).
