文字列 (またはファイル) が最後に確認してから変更されたかどうかを効率的に確認する方法を探しています。
したがって、この関数を 1,000,000 個のファイル/文字列 (各ファイル/文字列は 1000 バイト未満) に対して実行し、各ファイル/文字列の出力を保存します。
その後、数日待ってから、もう一度実行します。各ファイルが変更されたかどうかを調べる必要があります...
各ファイルの CRC32 を計算する必要がありますか? MD5? 他にもっと効率的なものはありますか？
CRC32 は、ファイル/文字列が変更されたかどうかを通知するのに十分ですか?
編集ファイルと文字列の両方で機能する必要があるため、ファイルのタイムスタンプは問題外です。
ファイルの場合、タイムスタンプを使用できます。
文字列については、バックアップ コピーを保持できます。
それらを比較してバックアップを書き直すだけで、CRCまたはMD5と同じくらい高速になる場合があります。
ファイルの場合、コンテンツを確認する必要がありますか? ファイルシステムは変更されたタイムスタンプを追跡します。
CRC32 または CRC64 で問題なく動作します。
ある種のハッシュ ルックアップの基礎として使用することもできます。
データは約 100 万個の 1kB 文字列/ファイルであり、数日ごとにチェックしたいとおっしゃいました。これが本当なら、1GB のデータを処理するのにそれほど時間はかからないので、パフォーマンスについて心配する必要はありません。
crc32 よりも衝突する可能性が低いため、md5 を使用することをお勧めします。Crc32 で十分ですが、それ以上の投資をしなくても、より良い結果を得ることができます。
編集：他の誰かが述べたように、文字列をバックアップと比較する方が高速です。(2 つの文字が異なるとすぐに中止できるため) ファイルから文字列を読み取る必要がある場合、これは 100% 真実ではありません。文字列がファイルから取得され、md5 を使用すると仮定すると、32 バイトに加えて、比較するすべての文字列の文字列の長さの平均を読み取る必要があります。バイトごとに比較すると、最小 2 バイト、最大 2 倍の文字列長を読み取る必要があります。したがって、多くの文字列の先頭が同じである場合 (32 文字より多い + 文字列の長さの平均が等しい)、ハッシュを使用すると高速になります。(間違っていたら訂正してください) これは理論的なケースであるため、文字ごとの比較に固執しても問題ありません。文字列の長さの平均が 32 バイトより大きい場合は、
しかし、すでに上で述べたように。その量のデータを処理する場合、パフォーマンスは問題になりません。
文字列比較は、crc32 や md5、または提案されている他のハッシュ アルゴリズムよりも効率的です。
手始めに、2 つの文字列が異なるとすぐに文字列比較から抜け出すことができますが、ハッシュ アルゴリズムでは、比較を行う前にファイルの内容全体をハッシュする必要があります。
さらに、ハッシュ アルゴリズムには、ハッシュを生成するために実行する必要がある操作がありますが、文字列比較は 2 つの値が等しいかどうかをチェックします。
最初の失敗 (ファイル/文字列ごと) で短絡するファイル/文字列の文字列ベースの比較により、優れたパフォーマンスが得られると思います。
Javaでは、次のことができます。
File file = new File(filePath);
file.lastModified();
私はこの種のものにMD5を使用していますが、十分に機能しているようです。.NET を使用している場合は、System.Security.Cryptography.MD5CryptoServiceProvider を参照してください。