Po přečtení všech vašich otázek ( unikátní omezení činí hash nepoužitelným? , 512bitový hash vs 4 128bitový hash a komprese textu adresy URL (nikoli zkrácení ) a uložení do mysql ), pochopil jsem, že váš problém je víceméně následující:
Je to tak?
Důležité jsou následující body:Jaký je formát adresy URL, kterou uložíte? Budete muset adresu URL číst zpět nebo o ní pouze aktualizovat informace, ale nikdy nehledat na základě dílčích adres URL atd.?
Za předpokladu, že URL ="http://www.somesite.com.tv/images/picture01 .jpg “ a že chcete uložit vše, včetně názvu souboru. Pokud se liší, uveďte prosím další podrobnosti nebo opravte mé předpoklady odpovědí .
-
If může ušetřit místo nahrazením některé skupiny znaků v URL. Ne všechny znaky ASCII jsou v adrese URL platné, jak můžete vidět zde:RFC1738 , takže je můžete použít k reprezentaci (a komprimaci) adresy URL. Například:použití znaku 0x81 k reprezentaci "http://" vám může ušetřit 6 znaků, 0x82 k reprezentaci ".jpg" vám může ušetřit další 3 bajty atd.
-
Některá slova mohou být velmi běžná (například „obrázek“, „obrázek“, „video“, „uživatel“). Pokud se rozhodnete pro kódování takových slov používat znaky 0x90 až 0x9f + jakýkoli jiný znak (takže 0x90 0x01, 0x90 0x02, 0x90 0xfa), můžete mít 16 * 256 =4 096 "položky ve slovníku" pro kódování nejpoužívanějších slov. K vyjádření 4–8 znaků použijete 2 bajty.
Upravit: jak si můžete přečíst ve zmíněném RFC výše, v URL můžete mít pouze tisknutelné ASCII znaky. To znamená, že by měly být použity pouze znaky 0x20 až 0x7F, s některými poznámkami provedenými v RFC. Takže jakýkoli znak po 0x80 (hexadecimální zápis by byl znakem 128 desítkové v tabulce ASCII) by neměl být použit. Pokud tedy lze vybrat jeden znak (řekněme 0x90) jako jeden příznak označující „následující bajt je označení ve slovníku, index, který použiji“. Jeden znak (0x90) * 256 znaků (0x00 až 0xFF) =256 záznamů ve slovníku. Můžete se ale také rozhodnout použít znaky 0x90 až 0x9f (nebo 144 až 159 v desítkové soustavě) k označení toho, že se jedná o příznak do slovníku, čímž získáte 16 *256 možností...
Tyto 2 metody vám mohou ušetřit spoustu místa ve vaší databázi a jsou reverzibilní, aniž byste se museli starat o kolize atd. Jednoduše si ve své aplikaci vytvoříte slovník a přejdete pomocí něj kódovat/dekódovat adresy URL, velmi rychle. vaše databáze mnohem lehčí.
Protože již máte +50 milionů adres URL, můžete na jejich základě generovat statistiky a vytvářet tak lepší slovník.
Použití hodnot hash :Hashe jsou v tomto případě kompromisem mezi velikostí a bezpečností. Jak špatné to bude, když dojde ke kolizi? A v tomto případě můžete použít narozeninový paradox abychom vám pomohli.
Přečtěte si článek, abyste pochopili problém:pokud by všechny vstupy (možné znaky v URL) byly ekvivalentní, mohli byste odhadnout pravděpodobnost kolize. A mohl byste vypočítat opak:jak široký by měl být váš rozsah vzhledem k vaší přijatelné pravděpodobnosti kolize a vašemu počtu souborů? A protože váš rozsah přesně souvisí s počtem bitů generovaných hashovací funkcí...
Upravit: pokud máte hashovací funkci, která vám dává 128 bitů, budete mít 2^128 možných výsledků. Takže váš „rozsah“ v narozeninovém paradoxu je 2^128:je to, jako by váš rok měl 2^128 dní místo 365. Vypočítáte tedy pravděpodobnost kolize („dva soubory být narozen ve stejný den s rokem které mají 2^128 dní místo 365 dnů). Pokud se rozhodnete použít hash, který vám dává 512 bitů, váš rozsah bude od 0 do 2^512...
A opět mějte na paměti RFC:ne všechny bajty (256 znaků) jsou platné ve světě internetu / URL. Pravděpodobnost kolize se tak snižuje. Lepší pro vás :).