Dopo aver letto tutte le tue domande ( vincolo unico rende gli hash inutili? , Hash a 512 bit contro 4 hash a 128 bit e compressione del testo URL (non abbreviato ) e archiviare in mysql ), ho capito che il tuo problema è più o meno il seguente:
È così?
I seguenti punti sono importanti:Com'è il formato dell'URL che salverai? Dovrai rileggere l'URL o semplicemente aggiornare le informazioni su di esso, ma non cercare mai in base a URL parziali, ecc?
Supponendo URL ="http://www.somesite.com.tv/images/picture01 .jpg " e che desideri archiviare tutto, incluso il nome del file. Se è diverso, fornisci maggiori dettagli o correggi le mie ipotesi di risposta .
-
Se può risparmiare spazio sostituendo alcuni gruppi di caratteri nell'URL. Non tutti i caratteri ASCII sono validi in un URL, come puoi vedere qui:RFC1738 , quindi puoi usarli per rappresentare (e comprimere) l'URL. Ad esempio:usare il carattere 0x81 per rappresentare "http://" può farti risparmiare 6 caratteri, 0x82 per rappresentare ".jpg" può farti risparmiare altri 3 byte, ecc.
-
Alcune parole potrebbero essere molto comuni (come "immagine", "immagine", "video", "utente"). Se scegli di utilizzare caratteri da 0x90 fino a 0x9f + qualsiasi altro carattere (quindi, 0x90 0x01, 0x90 0x02, 0x90 0xfa) per codificare tali parole, puoi avere 16 * 256 =4.096 "voci del dizionario" per codificare le parole più utilizzate. Utilizzerai 2 byte per rappresentare 4 - 8 caratteri.
Modifica: come puoi leggere nella menzionata RFC, nell'URL puoi avere solo i caratteri ASCII stampabili. Ciò significa che devono essere utilizzati solo i caratteri da 0x20 a 0x7F, con alcune osservazioni fatte nell'RFC. Quindi, qualsiasi carattere dopo 0x80 (notazione esadecimale, sarebbe il carattere 128 decimale nella tabella ASCII) non dovrebbe essere utilizzato. Quindi, se puoi scegliere un carattere (diciamo lo 0x90) come flag per indicare "il byte seguente è un'indicazione nel dizionario, l'indice che userò". Un carattere (0x90) * 256 caratteri (da 0x00 a 0xFF) =256 voci nel dizionario. Ma puoi anche scegliere di usare i caratteri da 0x90 a 0x9f (o da 144 a 159 in decimale) per indicare che sono un flag per il dizionario, dandoti così 16 *256 possibilità...
Questi 2 metodi possono farti risparmiare molto spazio nel tuo database e sono reversibili, senza doversi preoccupare di collisioni, ecc. Creerai semplicemente un dizionario nella tua applicazione e andrai a codificare/decodificare gli URL usandolo, molto velocemente, rendendo il tuo database molto più leggero.
Dato che hai già +50 milioni di URL, puoi generare statistiche basate su di essi, per generare un dizionario migliore.
Utilizzo degli hash :gli hash, in questo caso, sono un compromesso tra dimensioni e sicurezza. Quanto sarà grave una collisione? E in questo caso puoi usare il paradosso del compleanno per aiutarti.
Leggi l'articolo per capire il problema:se tutti gli input (possibili caratteri nell'URL) fossero equivalenti, potresti stimare la probabilità di una collisione. E potresti calcolare il contrario:data la tua probabilità di collisione accettabile e il tuo numero di file, quanto dovrebbe essere ampio il tuo intervallo? E poiché il tuo intervallo è esattamente correlato al numero di bit generati dalla funzione hash...
Modifica: se hai una funzione hash che ti dà 128 bit, avrai 2^128 possibili risultati. Quindi, il tuo "intervallo" nel paradosso del compleanno è 2^128:è come se il tuo anno avesse 2^128 giorni, invece di 365. Quindi, calcoli le probabilità di collisione ("due file essere nato nello stesso giorno, con un anno che hanno 2^128 giorni invece di 365 giorni). Se scegli di utilizzare un hash che ti dia 512 bit, il tuo intervallo andrebbe da 0 a 2^512...
E, ancora, tieni presente l'RFC:non tutti i byte (256 caratteri) sono validi nel mondo Internet / URL. Quindi, la probabilità di collisioni diminuisce. Meglio per te :).
