データベース テーブルと Lucene (おそらく Solr) インデックスがあります。目標は、データベース テーブルのインデックスを作成することです。行ごとに正確に 1 つのドキュメントです。でも：
- Lucene インデックスの初期状態は不明であり、既にほぼ同期されている可能性があります。また、存在しない行のドキュメントが含まれる場合もありますが、後で別のメカニズムによって削除されます。
- 再同期を実行しているアプリケーションは、プロセス中に複数回再起動する必要がある場合があります。再起動後に保存できる状態はほとんどない (理想的には何もない) ため、前もって設定の違いをブルート フォースしても機能しません。
- Lucene インデックスへの低レベル アクセスは許可されていません。それに対してクエリを実行できますが、できません。特定のフィールドの用語を直接列挙します。キーの検索や範囲内のキーのカウントは、クエリで実行できます。
- データベース内の行には、バージョン管理情報や ETag がありません。それらは一意のキーの 1 つの列にすぎないと想定できます。
古い文書や削除が必要な文書をここで処理する必要はありません。無駄な時間をできるだけ少なくして、最終的にすべての行にドキュメントがあることを確認する必要があるだけです。
古いドキュメントの更新または削除は、この再同期メカニズムが完了を示した後にのみ実行されると想定されるシステムの別の部分によって処理されます。(実際、堅牢な更新/削除システムは簡単なものでした...)
以前は、このタスクは力ずくのセット差分で達成されていましたが、これは特に大規模なデータ セットで問題が発生し、ソリューションは再開をサポートするために部分的な同期を実際に利用する必要があります: アプリケーションがその前に常に何らかの進行を行う場合再起動すると、最終的にストアが同期されます。
差分ダイジェストhttps://www.ics.uci.edu/~eppstein/pubs/EppGooUye-SIGCOMM-11.pdfは興味深いように見えましたが、データ ストアがそれ自体を計算するために必要なスマートさを備えている場合にのみ適用されるようです。この場合、ジョブを実行する単一のアプリケーションがあり、2 つのストアに対してクエリ、挿入、および削除を実行するだけです。
これまでのところ、ここには 3 つの基本的なケースがあると考えています。
- セットは大幅に同期していません。インデックスは空です。これは、いずれかのセットの最小の ID から開始し、ソースからレコードのバッチをクエリし、宛先の違いを追加/削除するだけで簡単に処理できます。残念ながら、これは最初はすぐに進行しますが、再起動するたびに「追いつく」時間が長くなるため遅くなります。
- セットはほぼ同期しています。おそらく、データセット全体のヒストグラムを生成し、ソースと「一致」しない個々のバケットにドリルダウンすることによって、これに対処する効率的な方法があるはずですが、それでもすべてのキーにアクセスして追加する必要がありますそれをある種のバケットハッシュにします。
- セットには膨大な数の微妙な違いがあります。それぞれの行数は同じですが、それらの〜60％は異なるキーを持っています。これは最悪のシナリオのように思えますが、特にありそうにないシナリオではありません。
これを解決するための確立された手法はありますか？実際、追加が必要なものを記録するために一種のトランザクション ログを使用していますが、それは通常の操作のみを処理でき、初期同期や移行後の修復は処理できません。
「私にとって」これを処理できる製品やシステムがあることは知っていますが、他の実装上の懸念があるため、現時点ではこのシステムを既存のコードベース内に実装する必要があります。未来。実際、これの要点は、他のソリューションを使用できるようにするために、現在のシステムを「中途半端な家」にすることです。
プロセスが完了すると自動的に削除されるプレースホルダー ドキュメントを追加することにより、システムの更新/削除部分がフル スキャンの進行状況を記録する目的で悪用される可能性があると思いますか? セットがほぼ同期しているときにフルスキャンを避けたいのですが...