生成/圧縮ユニークキー

Question

私の仕事では、多くのユーザーがおり、各ユーザーにはホームディレクトリのファイルセットがあります。あらかじめ定義されたルールのため、私は各ファイルにユーザーファイルの内容と作成時間に基づいてUID（一意のID）を与えました。しかし今、私は、ユーザーアカウントのファイル数が100万を超えることができないことを知りました。現在のUIDは約32文字です。現在のuidlがNoSQLデータベースで多くのスペースを使用しているため、UIDを約6（理想条件）の文字から約10-​​12文字の長さに減らすことができます。

現在のUIDLは私が問題を言い換えるてみましょう timestamp.prrocess_whichcreated_it.size

EDIT のように見えます。私が実際に必要とするのは、圧縮アルゴリズムです。

私は1,000,000文字列（各ユニーク）と32文字の長さのリストを持っています。私は、F（string）= s2のような圧縮関数fを必要とします。ここで、S2は長さが10文字であり、すべてのS2文字列は一意にマップされます。

Answer 1

古いUIDをソートしてインデックスを示す新しいUID古いUIDの

のソートされた配列に単純化された擬似コードは、次のようになります。

sorted <- sort(UID's) 
for each file: 
    file.UID <- sorted.indexOf(file.UID) 

Answer 2

それは非常に難しい、それを圧縮する一意のIDを取るようにしてUNIQUEそれを維持します。あなたは衝突する傾向があります。

@ amitの提案は本当に最高です。おそらく、彼の実装はちょっとglibでした。

AUTO INCREMENTING INTEGER "ID"列と文字列/ varchar "OldGUID"を持つ表を作成する方法について説明します。すべてのあなたの古い/現在のGUIDをテーブルに挿入すると、GUIDとより短い/圧縮された "ID"の間に1対1の一致があります。新しいGUIDを作成するときに、テーブルにINSERTするだけで、1対1のマッチングが維持されるので、長いバージョンと短いバージョンの間で切り替えることができます。

Answer 3

一意の識別子が必要な場合は、私の最初の考えはUUIDです。

ただし、汎用UUIDは16バイトを消費し、バイナリ形式です。それは6文字のあなたの要件を食肉しません。 32文字を使用する現在の方法と比較して、「唯一」は50％のスペースを節約します。

したがって、一般的なハッシュ関数で64ビットのUID（8バイト）を使用する方が穏やかな仕組みになります。良好なハッシュでは、生成されるUIDの総数が<100万未満である限り、衝突の可能性はかなり妥当なままです。それが受け入れられると思われるならば、8バイトはあなたのスペース要件にかなり近いようです。