RAMを考慮したURLまたはハッシュのインデックス

すべての質問を読んだ後（一意の制約によりハッシュが役に立たなくなりますか？> 、512ビットハッシュと4128ビットハッシュ> および urlテキスト圧縮（短縮ではない） ）そしてmysqlに保存する ）、あなたの問題は多かれ少なかれ次のとおりだと理解しました：

それですか？

重要な点は次のとおりです。保存するURLの形式はどのようになっていますか。 URLを読み返す必要がありますか、それとも情報を更新するだけで、部分的なURLなどに基づいて検索することはありませんか？

URL =" http://www.somesite.com.tv/images/picture01 .jpg "そして、ファイル名を含むすべてを保存したい。それが異なる場合は、詳細を提供するか、私の答えの仮定を修正してください 。

1. URL内の文字のグループを置き換えることでスペースを節約できる場合。 URLですべてのASCII文字が有効であるとは限りません。ここに表示されているように：RFC1738 、したがって、これらを使用してURLを表す（および圧縮する）ことができます。例：文字0x81を使用して「http：//」を表すと6文字節約でき、0x82を使用して「.jpg」を表すとさらに3バイト節約できます。

2. いくつかの単語は非常に一般的かもしれません（「画像」、「画像」、「ビデオ」、「ユーザー」など）。 0x90から0x9fまでの文字+その他の文字（つまり、0x90 0x01、0x90 0x02、0x90 0xfa）を使用してそのような単語をエンコードする場合、16 * 256=4,096の「辞書エントリ」を使用して最もよく使用される単語をエンコードできます。 2バイトを使用して4〜8文字を表します。

編集： 上記のRFCで読むことができるように、URLには印刷可能なASCII文字しか含めることができません。これは、RFCでいくつかの観察が行われている状態で、0x20から0x7Fの文字のみを使用する必要があることを意味します。したがって、0x80以降の文字（16進表記、ASCIIテーブルでは10進数の128文字）は使用しないでください。したがって、1つの文字（たとえば0x90）を1つのフラグとして選択して、「次のバイトは辞書内の指示であり、私が使用するインデックスである」ことを示すことができる場合。 1文字（0x90）* 256文字（0x00から0xFFまで）=辞書の256エントリ。ただし、0x90〜0x9f（または10進数で144〜159）の文字を使用して、それらが辞書のフラグであることを示すこともできます。これにより、16*256の可能性が得られます...

これらの2つの方法は、データベースのスペースを大幅に節約し、衝突などを心配することなく元に戻すことができます。アプリケーションで辞書を作成し、それを使用してURLをエンコード/デコードするだけで、非常に高速になります。データベースがはるかに軽量になります。

すでに+5,000万のURLがあるので、それらに基づいて統計を生成し、より良い辞書を生成できます。

ハッシュの使用 ：この場合のハッシュは、サイズとセキュリティの間のトレードオフです。衝突した場合、どの程度悪化しますか？この場合、誕生日のパラドックス あなたを助けるために。