概要:同期のためにデータをチャンク化するためのよく知られた手法はありますか? チャンクは、個別に送信されるデータのブロックと見なされます。
これはかなり広い質問かもしれません。提案があれば、より専門的なトピックを開始します。
Android タブレット データベース (SQLite) を、Web サービス経由でアクセスされる中央データベースと同期するためのコードを設計/作成します。メカニズムは、次の事実を反映する必要があります。
- 幅広い用途でご利用いただけます。アプリケーションはかなり単純にする必要があります。とにかく、彼らは主にオフラインで動作するはずです。
- データの量は、少量から大量まで (タブレットの技術的限界まで) です。
- Web サービスの実装は、顧客に依存する場合があります (つまり、アプリケーションは Web サービスを書き直す必要があってはなりません。たとえば、SOAP を保持し、REST を強制しないという歴史的な理由がある場合があります)。
- 場合によっては、特定の新しい Web サービスをアプリケーション用に作成できます (顧客サイトで同じテクノロジを使用)。
問題の核心は、同期中に移動されるデータのサイズを最小限に抑える方法です。問題は、非同期ダウンロードを実装する方法ではありません。(私は、Virgil Dobjanschi によるAndroid REST クライアント アプリケーションの開発で紹介されている実装手法を検討しています。)
これまでのところ、次の基本的な方法を見つけました (特定の順序ではありません)。
- 少量のデータに対するブルート フォース、つまりすべてを送受信し、ターゲット側 (ダウンロード時はタブレット上、アップロード時はリモート サーバー上) で違いを解決します。ここで (たとえば) データベース テーブル全体を、データの可能な最大のチャンクと見なすことができます。
- データのレコードの変更日 (タイムスタンプ) を使用し、最後の同期から記憶された日付に基づいて新しいレコードのみを同期します。これは、追加および変更されたレコードの場合は問題ありません。ただし、削除されたレコードには追加のメカニズムを使用する必要があります。ここで、単一のレコードは、可能な限り最小限のデータのチャンクと見なすことができます。
上記は、単一のデータ チャンクの同期用です。より現実的な状況では、より多くのレコードをチャンク化する必要があります。ここでは、チャンクは個別に送信できるデータのブロックであると考えています。送信が失敗した場合 (つまり、さまざまな理由でオフラインになった場合)、失敗したチャンクと転送されていないチャンクのみを同期する必要があります。
私にとって明らかなことは、チャンクには特定のサイズが必要であることです（データブロックを形成するには、約10 kBと言います）。
通信コストを削減するために、構築されたチャンク パッケージは、チャンクのレコードの一部が変更、追加、または削除されるまで同じままにする必要があります。チャンクは、中央サーバー側で構築されるか、タブレット デバイスで構築されるかに関係なく、同じように構築する必要があります。
他のチャンクは、変更されたデータを含むチャンクの影響を受けません。このようにして、両側のチャンクごとに SHA ダイジェストを計算でき、どのチャンクを同期する必要があるかを簡単に見つけることができるとします。
チャンクを決定する方法に関する標準的な手法、論文、例はありますか?
ありがとう