Après avoir lu toutes vos questions ( la contrainte unique rend les hachages inutiles ? , Hachage 512 bits contre 4 hachage 128 bits et compression de texte d'url (pas de raccourcissement ) et stockage dans mysql ), j'ai compris que votre problème était plus ou moins le suivant :
C'est ça ?
Les points suivants sont importants :Quel est le format de l'URL que vous allez enregistrer ? Aurez-vous besoin de relire l'URL, ou simplement de mettre à jour les informations à son sujet, mais de ne jamais effectuer de recherche basée sur des URL partielles, etc. ?
En supposant que URL ="http://www.somesite.com.tv/images/picture01 .jpg " et que vous souhaitez tout stocker, y compris le nom du fichier. Si c'est différent, veuillez fournir plus de détails ou corriger mes hypothèses de réponse .
-
Si peut économiser de l'espace en remplaçant un groupe de caractères dans l'URL. Tous les caractères ASCII ne sont pas valides dans une URL, comme vous pouvez le voir ici :RFC1738 , vous pouvez donc les utiliser pour représenter (et compresser) l'URL. Par exemple :utiliser le caractère 0x81 pour représenter "http://" peut vous faire gagner 6 caractères, 0x82 pour représenter ".jpg" peut vous faire gagner encore 3 octets, etc.
-
Certains mots peuvent être très courants (comme "image", "image", "vidéo", "utilisateur"). Si vous choisissez d'utiliser les caractères 0x90 jusqu'à 0x9f + tout autre caractère (donc, 0x90 0x01, 0x90 0x02, 0x90 0xfa) pour encoder ces mots, vous pouvez avoir 16 * 256 =4 096 "entrées de dictionnaire" pour encoder les mots les plus utilisés. Vous utiliserez 2 octets pour représenter 4 à 8 caractères.
Modifier : comme vous pouvez le lire dans le RFC mentionné ci-dessus, dans l'URL, vous ne pouvez avoir que les caractères ASCII imprimables. Cela signifie que seuls les caractères 0x20 à 0x7F doivent être utilisés, avec quelques observations faites dans la RFC. Ainsi, tout caractère après 0x80 (notation hexadécimale, serait le caractère 128 décimal dans la table ASCII) ne doit pas être utilisé. Donc, si vous pouvez choisir un caractère (disons le 0x90) comme drapeau pour indiquer "l'octet suivant est une indication dans le dictionnaire, l'index que j'utiliserai". Un caractère (0x90) * 256 caractères (0x00 à 0xFF) =256 entrées dans le dictionnaire. Mais vous pouvez aussi choisir d'utiliser les caractères 0x90 à 0x9f (ou 144 à 159 en décimal) pour indiquer qu'ils sont un drapeau au dictionnaire, vous donnant ainsi 16 *256 possibilités...
Ces 2 méthodes peuvent vous faire gagner beaucoup d'espace dans votre base de données et sont réversibles, sans avoir à vous soucier des collisions, etc. Vous allez simplement créer un dictionnaire dans votre application et aller encoder/décoder les URL en l'utilisant, très rapidement, ce qui rend votre base de données beaucoup plus légère.
Puisque vous avez déjà +50 millions d'URL, vous pouvez générer des statistiques basées sur celles-ci, pour générer un meilleur dictionnaire.
Utiliser des hachages :Les hachages, dans ce cas, sont un compromis entre la taille et la sécurité. À quel point cela sera-t-il grave si vous obtenez une collision ? Et dans ce cas, vous pouvez utiliser le paradoxe de l'anniversaire pour vous aider.
Lisez l'article pour comprendre le problème :si toutes les entrées (caractères possibles dans l'URL) étaient équivalentes, vous pourriez estimer la probabilité d'une collision. Et pourrait calculer le contraire :compte tenu de votre probabilité de collision acceptable et de votre nombre de fichiers, quelle devrait être l'étendue de votre plage ? Et puisque votre plage est exactement liée au nombre de bits générés par la fonction de hachage...
Modifier : si vous avez une fonction de hachage qui vous donne 128 bits, vous aurez 2^128 résultats possibles. Ainsi, votre "plage" dans le paradoxe des anniversaires est de 2^128 :c'est comme si votre année avait 2^128 jours, au lieu de 365. Ainsi, vous calculez les probabilités de collision ("deux fichiers être né dans la même journée, avec un an qui ont 2^128 jours au lieu de 365 jours). Si vous choisissez d'utiliser un hachage qui vous donne 512 bits, votre plage ira de 0 à 2^512...
Et, encore une fois, gardez à l'esprit la RFC :tous les octets (256 caractères) ne sont pas valides dans le monde Internet/URL. Ainsi, la probabilité de collisions diminue. Mieux pour vous :).
