6

1) ハッシュの衝突を非常に少なくするために、sha1 自体を処理するのではなく、sha1 の 128 ビットの半分だけを使用して回避できますか? これが暗号化ハッシュには適していないことは理解していますが、必要なのはハッシュ テーブル キーのハッシュだけです。

2）計算時間は優先事項ではなく、それに加えて、非常に小さなデータをハッシュしています。特に、私は主に 2 つまたは 3 つの 64 ビット ハッシュを取得し、それらをハッシュして別の 64 ビット ハッシュを取得します。この目的で sha1 よりも優れたオプションはありますか? 繰り返しますが、衝突はほとんど起こらないはずです。

3) 私は SQL 初心者です。SQL の ID として 64 ビット ハッシュを使用するのは良い考えですか? 64 ビット ID は sqlite または postgres でパフォーマンスの問題を引き起こしますか? 複数のデータベース (Lucene インデックスを含む) にまたがるデータを調整する必要があるので、自動インクリメントされた ID を気にするのではなく、テーブルでハッシュを直接処理する必要があると考えました (これは 1 つのデータベースでのみ意味があり、すべてのデータ ストア間)。私は 64 ビットが良い妥協点だと考えています。起こりそうにない衝突には十分な大きさですが、スペース (およびルックアップ時間?) を節約できます。

4) CRC-64 はどうですか? それは十分にランダムな分布を生成しますか?

4

5 に答える 5

6

十分なレコードがほとんどない場合、64 ビットでハッシュ衝突が発生しないことはほぼ確実です。おそらくあなたはこの部類に入ると思います。

sha1 のような暗号化ハッシュを切り詰めても問題はないはずです。ハッシュに内部構造がある場合、暗号化ハッシュとしては不十分であり、構造がない場合、ビットの任意のサブセットである必要があるためです。かなりランダム。私はそれをIDに使用することについて話しているだけであり、暗号化の目的ではないことに注意してください!

しかし実際には、SQL にはある種の GUID がありませんか? もしそうなら、なぜそれを使わないのですか？

于 2009-04-16T04:04:18.637 に答える
4

ハッシュの長さの比較については、http://en.wikipedia.org/wiki/List_of_hash_functionsを参照してください。

また、注意: SHA-1 は 128 ビットではなく 160 ビットです。

于 2009-04-16T03:41:27.833 に答える
3

キーには、一意性の高い確率ではなく、絶対的な一意性が必要です。データベース間の互換性のために、キーのハッシュの代わりに GUID を使用することをお勧めします。クイック ルックアップ メカニズムとしてハッシュを生成します。これには一意ではないインデックスを設定できますが、衝突が発生した場合は、実際のデータを比較して、それらが同じであることを確認する必要があります。データベースの同期では、(インデックスを使用してすばやく) ハッシュを確認できます。衝突が見つかった場合は、データが同じかどうかを解決するため、GUID を解決する必要があります。競合がない場合は、不足しているエントリを必要とするデータベースを更新し、他のデータベースの GUID を使用して挿入します。

私も、スペースを節約するためにハッシュの独自のハッシュを作成することにほとんど意味がないと思います。すでに他のハッシュがある場合は、それらを使用してください (追加し、再ハッシュしないでください)。そうでない場合は、MD5 や SHA1 などの標準のハッシュ関数を使用して、結果のデータを保存してください。

于 2009-04-16T03:49:04.430 に答える
2

64ビットハッシュを使用すると、6.1×10 8レコードとの衝突の可能性が1％になります。（他の組み合わせについては、誕生日の問題に関するWikipediaのページを参照してください。）1秒おきのビットの最初の64ビット、または最後のビットを破棄できますが、ハッシュのプロパティに違いはありません。

于 2011-05-25T10:39:09.387 に答える