2017-02-09 1 views
2

データベーステーブルの主キーを作成するためにハッシュアルゴリズムを使用しています。私はSHA-1アルゴリズムを使用しています。データベースには、SHA-1の実装も含まれています。ハッシュを計算する関数は、16進数の値を40文字で返します。したがって、私はchar(40)カラムに16進文字を格納しています。データベースにSHA-1を40桁の16進数よりも少ない領域に格納

テーブルには、> 200 Mio以上の行があります。私はハッシュを格納するデータ集約的ではない方法を探しています。 40文字×200ミオ。行はいくつかのGBの記憶容量を必要とします... hexはbase16なので、私は基本的な256にそれを約20文字に必要な文字の量を減らすことを望んで格納しようとすることができると考えました。ベース256での圧縮の実装に関するヒントや論文はありますか? ブロブとして

+2

これはプログラミング上の質問で、これは話題にはなりません。格納しようとしているオブジェクトは160ビットの数値で、16進数を文字列として格納するのではなく、160ビットの数値として保存するだけです。 (同様に、5桁の10進数を格納しようとすると、 'char [5]'ではなく 'int'に格納します)。 –

+0

@DavidRicherby私は' int'を格納できません私は衝突のない鍵が必要で、ハッシュ関数の出力は 'char(40)'です。 intに16進文字列を格納すると、その数が非常に多くなるので、より多くのバイトが必要になると思います。 –

+0

もちろん、 'int'は160ビットの数値を保持しません。しかし、ある種の整数形式でデータを格納すると、スペースは少なくなります。文字列として格納すると、1バイトあたり4ビットの有用なデータが得られます(基本システムが16ビット文字セットを使用している場合よりも少なくなります)。 –

答えて

2

SHA-1の値は20バイトです。これらの20バイトのビットはすべて重要です。圧縮する方法はありません。バイトを16進表記で格納することで、スペースを半減できます。バイトを格納するには、正確に2つの16進数が必要です。したがって、基本となる値を圧縮することはできませんが、16進数よりも優れたエンコーディングを使用できます。

Storing as a blobが正しい答えです。これはベース256です。各バイトをエンコーディングなしでそのバイトとして格納しているため、オーバーヘッドが発生します。無駄なスペース:0

これを行うことはできず、印刷可能な文字列を使用する必要がある場合は、よりコンパクトなエンコーディングを使用して16進数よりも優れています。 16進数の場合、記憶要件は最小の2倍です(各文字が1バイトとして格納されていると仮定します)。 Base64を使用すると、ストレージ要件を3バイトあたり4文字にすることができます。つまり、値を格納するには28文字が必要です。実際には、長さが21ではなく20バイトであることがわかっているので、base64エンコーディングは常に=で終了するため、27文字のを格納し、デコードする前に末尾=を復元すればよい。

さらに多くの文字を使用すると、エンコードをさらに改善できます。 Base64は、利用可能な256バイト値のうち64コードポイントを使用します。 ASCII(事実上の可搬性)は95個の印字可能な文字(スペースを含む)を持っていますが、共通の "base95"エンコーディングはありません。 Base85は中間的な選択肢ですが、実際にはいくらかの使用方法があり、印刷可能な25のASCII文字に20バイトの値を格納することができます。

2
  • ストアを:あなたは160を持っている:代わりに4文字あたり8ビットのデータを保存するには、
  • は、いくつかの文字を切り取り、2倍の圧縮(あなたががそれを変換するためにいくつかの方法が必要です)でありますユニバースが終了してもユニークキーには128ビットで十分です。ほとんどの場合、80ビットでも十分です(暗号化保護は必要ありません)。アンチコリジョンアルゴリズムを使用している場合は、36または40ビットで十分です。
+0

しかし、見通しを保つ:典型的な合計行サイズと比較して20バイトが有意義に保存されていますか? – TripeHound

+0

悲しいことに、BLOBとして保存することはできません。私はCHAR、VARCHAR、DECIMAL、DATE、TIMESTAMP、BOOLEAN、GEOMETRYを持っています。 –

関連する問題