3

ファイル名とその他の詳細をテーブルに保存し、ファイル名の sha1 ハッシュを PK として使用する予定です。

  • Q1. SHA1 PK は、連続して増減する数値にはなりません。では、データベースが/search_intoを維持し、そのキーにインデックスを付けるために、より多くのリソースを消費しますか? データベースに40文字の値として保持することにした場合。

  • Q2. 私はここで読みました: https://stackoverflow.com/a/614483/986818データを binary(20) フィールドとして保存します。誰かがこの点で私にアドバイスできますか:

  • a) この列を TYPE=integer、LENGTH=20、
    COLLATION=binary、ATTRIBUTES=binary として作成する必要がありますか?
  • b) MySQL または Perl の sha1 値を変換してテーブルに格納する方法は?
  • c) この 20 文字の値に重複の危険性はありますか?

**

- - - - -アップデート - - - - - - -

**

要件は、ファイル名でテーブルを検索することです。ユーザーがファイル名を指定すると、テーブルを検索し、ファイル名が存在しない場合は追加します。したがって、varchar(100) ファイル名フィールドでインデックスを作成するか、ファイル名の sha1 を使用して列を生成します。varchar フィールドのインデックス作成と比較して、MySql のインデックス作成が簡単になることを願っています。また、プログラムの sha1 値を sha1 列に対して使用して検索することもできます。何を言います？主キーまたは単にインデックス化されたキー: DBIx は PK を使用するのが好きなので、PK を選択します。PKまたはINDEX + UNIQは、システムのオーバーヘッドと同じ量になります（そう思いました）

4

5 に答える 5

0

OK、ファイル名に非常に短いハッシュを使用し、衝突を受け入れます。整数型を使用してください (はるかに高速です!!!)。たとえば、md5(filename) を使用してから、最初の 8 文字を使用して整数に変換できます。SQL は次のようになります。

CREATE TABLES files (
  id INT auto_increment,
  hash INT unsigned,
  filename VARCHAR(100),

  PRIMARY KEY(id),
  INDEX(hash)
);

次に、次を使用できます。

SELECT id FROM files WHERE hash=<hash> AND filename='<filename>';

次に、ハッシュは他のほとんどのファイル (通常は他のすべてのファイル) を分類するために使用され、ファイル名はいくつかのハッシュ衝突から正しいエントリを選択するために使用されます。

perl で整数のハッシュ キーを生成するには、md5() と pack() を使用することをお勧めします。

于 2012-08-19T20:56:17.590 に答える
0

ここで暗号的に安全なハッシュを使用する理由はありません。代わりに、これを行う場合は、通常のハッシュを使用してください。ここを参照してください: https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed

ハッシュは 40 文字の値ではありません! これは 160 ビットの数値であり、そのように格納する必要があります (20 文字のバイナリ フィールドとして)。編集：コメント2でそれについて言及したようです。はい、間違いなくそうする必要があります。しかし、あなたが使っているプログラミング言語がわからないので、その方法を教えることはできません。Edit2: perl だと思います - 残念ながら perl で変換する方法はわかりませんが、"pack" 関数を探してください。

いいえ、整数型として作成しないでください。最大整数は 128 ビットで、全体を保持することはできません。実際には128ビットに切り捨てることができますが、実際には害はありません.

とにかく、より単純なハッシュを使用することをお勧めします。危険を冒して衝突を無視することもできますが、適切に行うと、それらを処理する必要があります。

于 2012-08-19T20:08:24.290 に答える
0

データベースに40文字の値として保持することにした場合。

文字シーケンスをキーとして使用すると、明らかな理由でパフォーマンスが低下します。

また、PK は一意である必要があります。おそらく衝突が発生する可能性は低いでしょう (理論的には、PK を作成する関数にそれを使用するのは不適切なようです。さらに
、使用するファイル名とハッシュを知っている人は、すべてのデータベース ID を知っているでしょう。これは考慮すべきことではありません。

于 2012-08-19T20:13:15.493 に答える
0

Q1: はい、1 つの整数 (4 バイト) だけでなく CHAR(40) を含むノードの B ツリーを構築する必要があります。INDEX がメモリに保持されている限り、速度はほぼ同じです。エントリは約 10 倍大きいため、メモリ内に保持するには 10 倍のメモリが必要です。BUT: とにかくハッシュでルックアップしたいでしょう。そのため、主キーとして、またはインデックスとして持つ必要があります。

Q2: CREATE TABLE test (ID BINARY(40), ...); のようにテーブル フィールドを作成するだけです。後で INSERT INTO test (ID, ..) VALUES (UNHEX('4D7953514C'), ...); を使用できます。

-- について: この 20 文字の値に重複の危険性はありますか?

確率は 2^(8*20) に 1 です。1,46 * 10^48 に 1 つ ... または 14615016373309029182036848327163*10^18 の 1 つ。したがって、その可能性は非常に非常にありそうにありません。

于 2012-08-19T20:13:33.030 に答える
0

主キーには標準の自動インクリメント整数を使用します。ファイル名の一意性が重要な場合 (そのように聞こえます)、ファイル名自体または派生した正規バージョンのファイル名に UNIQUE 制約を追加できます。ほとんどの言語/フレームワークには、パスの正規バージョンを取得するための何らかの方法があります (絶対、標準化されたケースなどに関連する)。

私の提案を実装するか、元の計画を追求する場合は、複数の文字列が同じファイル名/パスにマップされる可能性があることに注意してください。両方のバージョンは異なるハッシュを持ち、一意性制約を渡しますが、実際には両方とも同じファイルを参照します。これはオペレーティング システムによって異なり、問題になる場合とそうでない場合があります。心に留めておくべきことがあります。

于 2012-08-19T20:18:36.287 に答える