スキームの問題の1つは、繰り返される行にはハッシュが繰り返されることです。これらの行の 1 つがいつ追加または削除されたかを特定できませんでした
非常に良い点ですが、問題ではありません。繰り返される行は重複であり、すべての重複は処理の次の段階で削除されます。はい、あなたは正しいですが、それは問題ではありません。
「差分」リンクをクリックすると、アプリケーションと思われるものの説明が記載されたページに移動しますか? ダウンロード リンクはありません。どの言語のコードもありません。何が足りないのでしょうか。
バイトレベルの粒度について話している人もいます。これは必要ありません。行内の変更が行全体に影響するため、行の何かが変更された場合、行全体 (レコード) を再処理する必要があるため、行レベルの粒度のみが必要です。
したがって、それぞれ約 100 万行の 2 つのファイル (今日のスナップショットと昨日のスナップショット) で、約 1000 文字 (バイナリなし) の行を比較しています。
したがって、SHA256 のような安全なハッシュを使用すると (MD5 には衝突があり、比較すると遅い)、HO ラップトップで約 30MB/秒を処理できます。もちろん、サーバーはそれをはるかに高速に噛み砕きます。
したがって、ファイルが約 1GB の場合、すべてのハッシュを作成するには約 33 秒かかり、Windows ページ メモリを使用して 1Gb ファイルを読み取るには約 30 秒かかります。恐ろしくない
これで、各ファイルの行を表すハッシュの 2 つの配列ができました。それらを並べ替えると、バイナリ検索を使用できるようになるため、新しいファイル ハッシュを反復処理して、古いファイル ハッシュで一致するものを探します。見つからない場合は、その行が変更ファイルに追加されます。
行の本 (従来のデータベース) はあらゆる面で未知であることに注意してください。行の順序、変更の場所、変更の種類を保証するものではありません。
ページごとに先読みするという提案は適切ですが、最初の変更までは 2 つのファイルが同じ順序であると想定しています。これは想定できません。行 (行) の順序は任意です。また、任意のブロックサイズを選択すると、行の粒度に違反します。このタスクでは、行は不変です。
ファイル比較キャプチャ: この方法は、スナップショット差分法とも呼ばれます。この方法は、データ ウェアハウスにとって重要なファイルのビフォア イメージとアフター イメージを保持することで機能します。レコードを比較して変更を見つけ、レコード キーを比較して挿入と削除を見つけます。この手法は、通常、トリガーが存在せず、トランザクション ログが存在しないか独自の形式であるレガシー システムの場合に最も適しています。ほとんどのレガシー データベースには、データをファイルにダンプするための何らかのメカニズムがあるため、この手法では定期的なスナップショットを作成し、結果を比較して変更レコードを生成します。確かに、静的キャプチャのすべての問題がここにあります。情報の行全体を比較するという課題と、キーの識別と照合により、複雑さが増します。この手法は本質的に複雑であり、通常は望ましくありませんが、場合によっては、これが唯一の解決策になることがあります。
これはここで最も重要です。テラバイトのデータ ウェアハウスの領域に進むにつれて、データ ウェアハウスを毎晩ゼロから再構築する機能は、恐竜のようになります。データ ウェアハウスを更新するための論理的かつ効率的なアプローチには、何らかの形式の増分更新戦略が含まれます。
それで、私は正しい軌道に乗っていると思いますか？btree インデックスは有利ではないでしょうか?