Depois de ler todas as suas perguntas ( restrição única torna os hashes inúteis? , hash de 512 bits vs 4 hash de 128 bits e compressão de texto de URL (não encurtando ) e armazenando no mysql ), entendi que seu problema é mais ou menos o seguinte:

É isso?

Os seguintes pontos são importantes:Como é o formato da URL que você vai salvar? Você precisará ler o URL de volta ou apenas atualizar as informações sobre ele, mas nunca pesquisar com base em URLs parciais, etc?

Assumindo URL ="http://www.somesite.com.tv/images/picture01 .jpg " e que você deseja armazenar tudo, incluindo o nome do arquivo. Se for diferente, forneça mais detalhes ou corrija minhas suposições de resposta .

1. 
   If pode economizar espaço substituindo algum grupo de caracteres na URL. Nem todos os caracteres ASCII são válidos em um URL, como você pode ver aqui:RFC1738 , para que você possa usá-los para representar (e compactar) a URL. Por exemplo:usar o caractere 0x81 para representar "http://" pode fazer você economizar 6 caracteres, 0x82 para representar ".jpg" pode economizar mais 3 bytes, etc.
   
2. 
   Algumas palavras podem ser muito comuns (como "imagem", "imagem", "vídeo", "usuário"). Se você optar por usar os caracteres 0x90 até 0x9f + qualquer outro caractere (portanto, 0x90 0x01, 0x90 0x02, 0x90 0xfa) para codificar tais palavras, você pode ter 16 * 256 =4.096 "entradas de dicionário" para codificar as palavras mais usadas. Você usará 2 bytes para representar de 4 a 8 caracteres.
   

Editar: como você pode ler no RFC mencionado, acima, na URL você só pode ter os caracteres ASCII imprimíveis. Isso significa que apenas os caracteres 0x20 a 0x7F devem ser usados, com algumas observações feitas na RFC. Portanto, qualquer caractere após 0x80 (notação hexadecimal, seria o caractere 128 decimal na tabela ASCII) não deve ser usado. Então, se pode escolher um caractere (digamos o 0x90) para ser um sinalizador para indicar "o byte a seguir é uma indicação no dicionário, o índice que vou usar". Um caractere (0x90) * 256 caracteres (0x00 até 0xFF) =256 entradas no dicionário. Mas você também pode optar por usar os caracteres 0x90 a 0x9f (ou 144 a 159 em decimal) para indicar que eles são um sinalizador para o dicionário, oferecendo assim 16 *256 possibilidades...

Esses 2 métodos podem economizar muito espaço em seu banco de dados e são reversíveis, sem a necessidade de se preocupar com colisões, etc. seu banco de dados muito mais leve.

Como você já tem mais de 50 milhões de URLs, você pode gerar estatísticas com base neles, para gerar um dicionário melhor.

Usando hashes :Hashes, neste caso, são uma troca entre tamanho e segurança. Quão ruim será se você sofrer uma colisão? E neste caso você pode usar o paradoxo do aniversário a> para ajudá-lo.

Leia o artigo para entender o problema:se todas as entradas (possíveis caracteres na URL) fossem equivalentes, você poderia estimar a probabilidade de uma colisão. E poderia calcular o oposto:dada sua probabilidade de colisão aceitável e seu número de arquivos, quão amplo deve ser o seu alcance? E como seu intervalo está exatamente relacionado ao número de bits gerados pela função hash ...

Editar: se você tiver uma função de hash que lhe dê 128 bits, você terá 2^128 resultados possíveis. Então, seu "intervalo" no paradoxo do aniversário é 2^128:é como se seu ano tivesse 2^128 dias, em vez de 365. Então, você calcula as probabilidades de colisão ("dois arquivos sendo nascido no mesmo dia, com um ano que tem 2^128 dias em vez de 365 dias). Se você optar por usar um hash que lhe dê 512 bits, seu intervalo irá de 0 a 2^512...

E, novamente, tenha em mente o RFC:nem todos os bytes (256 caracteres) são válidos no mundo da internet/URL. Assim, a probabilidade de colisões diminui. Melhor para você :).