6
1）本当に低いハッシュコリジョンの目的のために、sha1自体を扱うのではなく、sha1の128ビットの半分を使用するだけで取り除くことができますか？私はこれが暗号ハッシュには適していないと理解していますが、ハッシュテーブルキーのハッシュだけが必要です。sha1ハッシュの64ビットのみをIDとして使用することはできますか？
2）計算時間は優先順位ではなく、それ以外にも非常に小さなデータがハッシュされています。特に、私は主に2〜3つの64ビットハッシュを取得し、別の64ビットハッシュを取得するためにそれらをハッシュします。この目的のためにsha1より良い選択肢がありますか？再び、衝突は非常に起こりにくいはずです。
3）私はsql newbです。 sqlのIDとして64ビットハッシュを使用するのは良い考えですか？ 64ビットのIDはsqliteやpostgresのパフォーマンス上の問題を引き起こしますか？私は複数のデータベース（Luceneインデックスを含む）にまたがってデータを調整する必要があるので、自動インクリメントIDで悩むのではなく、テーブルで直接ハッシュを処理する必要があると考えました（これは1つのデータベースでのみ意味があります。すべてのデータストアにわたって）。私は64ビットが良い妥協策であると考えています。衝突はほとんど起こりませんが、スペース（および参照時間）を節約します。
4）CRC-64はどうですか？それは十分にランダムな分布を生み出しますか？
私はGUID/UUIDが私の望むものだと思います。しかし、sqliteサポートが適切かどうかは分かりませんので、私はそれを調べます。私が言ったように、私はsql newbです。 – Jegschemesch
Sqlite3はUUIDをサポートするように簡単に拡張することができます。以前はiPhoneアプリで成功しました。 –
私はこの回答に同意します。私は数百万行のhundretsでいっぱいのテーブルを持っており、パフォーマンスの理由から文字列としてsha1ハッシュの代わりに最初の64ビットをunsgined整数キーとして使用しています。 3億5千万の行で私は56ビットでいくつかの衝突を抱えていました。私はいつも日付と64ビットハッシュキーを組み合わせて、ハッシュキーと日付の両方をマッチさせる必要があります。この方法を使用すると、衝突を引き起こす可能性のある1日あたり3,000万行しかないため、長期的に発生する機会が大幅に減ります。衝突が起こると情報の単一の平和が間違ったものになります - 私の場合、節約に値するものです。 – bhelm