Na het lezen van al uw vragen ( unieke beperking maakt hashes nutteloos? , 512 bit hash versus 4 128bit hash en url-tekstcompressie (niet verkorten ) en opslaan in mysql ), heb ik begrepen dat uw probleem min of meer het volgende is:
Is dat het?
De volgende punten zijn belangrijk:Hoe is het formaat van de URL die u opslaat? Moet u de URL teruglezen of alleen informatie erover bijwerken, maar nooit zoeken op basis van gedeeltelijke URL's, enz.?
Uitgaande van URL ="http://www.somesite.com.tv/images/picture01 .jpg " en dat je alles wilt opslaan, inclusief de bestandsnaam. Als het anders is, geef dan meer details of corrigeer mijn aannames voor het antwoord .
-
If kan ruimte besparen door een groep tekens in de URL te vervangen. Niet alle ASCII-tekens zijn geldig in een URL, zoals je hier kunt zien:RFC1738 , zodat u deze kunt gebruiken om de URL weer te geven (en te comprimeren). Bijvoorbeeld:als u teken 0x81 gebruikt om "http://" weer te geven, kunt u 6 tekens opslaan, 0x82 om ".jpg" weer te geven kan u nog eens 3 bytes besparen, enz.
-
Sommige woorden kunnen heel gewoon zijn (zoals "afbeelding", "foto", "video", "gebruiker"). Als u ervoor kiest om tekens 0x90 tot 0x9f + elk ander teken (dus 0x90 0x01, 0x90 0x02, 0x90 0xfa) te gebruiken om dergelijke woorden te coderen, kunt u 16 * 256 =4.096 "woordenboekvermeldingen" gebruiken om de meest gebruikte woorden te coderen. U gebruikt 2 bytes om 4 - 8 tekens weer te geven.
Bewerken: zoals je kunt lezen in de genoemde RFC hierboven, kun je in de URL alleen de afdrukbare ASCII-tekens hebben. Dit betekent dat alleen de tekens 0x20 tot 0x7F moeten worden gebruikt, met enkele opmerkingen in de RFC. Dus elk teken na 0x80 (hexadecimale notatie, zou teken 128 decimaal zijn in de ASCII-tabel) mag niet worden gebruikt. Dus als je één teken (laten we zeggen de 0x90) kunt kiezen als één vlag om aan te geven "de volgende byte is een indicatie in het woordenboek, de index die ik zal gebruiken". Eén teken (0x90) * 256 tekens (0x00 tot 0xFF) =256 vermeldingen in het woordenboek. Maar je kunt er ook voor kiezen om de tekens 0x90 tot 0x9f (of 144 tot 159 in decimaal) te gebruiken om aan te geven dat ze een vlag zijn voor het woordenboek, waardoor je 16 *256 mogelijkheden krijgt...
Deze 2 methoden kunnen u veel ruimte in uw database besparen en zijn omkeerbaar, zonder dat u zich zorgen hoeft te maken over botsingen, enz. U maakt eenvoudig een woordenboek in uw toepassing en codeert/decodeert URL's ermee, heel snel, waardoor uw database veel lichter.
Aangezien u al +50 miljoen URL's heeft, kunt u op basis daarvan statistieken genereren om een beter woordenboek te genereren.
Hashes gebruiken :Hashes zijn in dit geval een afweging tussen grootte en veiligheid. Hoe erg zal het zijn als je een aanrijding krijgt? En in dit geval kun je de verjaardagsparadox om u te helpen.
Lees het artikel om het probleem te begrijpen:als alle invoer (mogelijke tekens in de URL) equivalent waren, zou je de kans op een botsing kunnen schatten. En zou het tegenovergestelde kunnen berekenen:gezien uw aanvaardbare aanvaringskans en uw aantal bestanden, hoe breed moet uw bereik zijn? En aangezien je bereik exact gerelateerd is aan het aantal bits dat door de hash-functie wordt gegenereerd...
Bewerken: als je een hash-functie hebt die je 128 bits geeft, heb je 2^128 mogelijke uitkomsten. Dus je "bereik" in de verjaardagsparadox is 2^128:het is alsof je jaar 2^128 dagen heeft, in plaats van 365. Je berekent dus de kansen op een botsing ("twee bestanden geboren worden op dezelfde dag, met een jaar die 2^128 dagen hebben in plaats van 365 dagen). Als je ervoor kiest om een hash te gebruiken die je 512 bits geeft, zou je bereik gaan van 0 tot 2^512...
En nogmaals, houd rekening met de RFC:niet alle bytes (256 karakters) zijn geldig in de internet/URL-wereld. De kans op botsingen neemt dus af. Beter voor jou :).