サーバーからクライアントへの部分的なデータベースモデルの同期

Question

これは、概念的な問題ではなく、必ずしも特定のテクノロジに束縛されていません。 サーバー上にデータベースがあり、そのデータベースのコンテンツにアクセスするいくつかのREST/JSON APIと、APIで取得したデータを表示するモバイルクライアントがあるとします。

クライアントにいくつかのキャッシュメカニズムがあり、クライアントが読んでいる間だけデータにオフラインでアクセスできるようにするのもいいでしょう。（私の場合は、オフラインクライアントへの書き込みアクセスを拒否するのもいいです起こりうる厄介な葛藤をすべて管理する必要はありません）。

これを解決する良い方法は、クライアントにサーバーデータベースモデルのサブセットを用意し、サーバーからクライアントにデータを同期させることです。 ローカルデータベースにアクセスすると、すぐに結果が返されますが、サーバーへの更新要求もトリガーされます。サーバが変更されたデータを返す場合、クライアントモデルはそれをローカルデータベースと同期させ、データ変更の表示を通知する。

もちろん、最終的な目標は、インターネット接続の安定性に関係なく情報を参照できることです。ユーザーがデータを変更しない限り、接続ダイアログなどで迷惑をかけることはありません。

実装の観点から...一方では、異なるベンダーのものである可能性があるため、サーバーデータベースをクライアントデータベースに直接接続することは悪い考えです。少なくとも、両方のデータベースの実装よりもベンダーに依存しないモデルが必要であると思います。一方、サーバー・データベースから何らかのトランスポート・フォーマットにデータを変換し、それをクライアント・データベースに戻すよりも、オーバーヘッドのように思えます。

どのようにエレガントで維持可能な方法でそれを解決するための提案はありますか？

Answer 1

私は大規模なデータベースの小さな部分をハンドセットにローカルに同期させるアプリケーションに取り組んでいます。ハンドセットで発生しなければならない初期のプリロードがありますが、その後はバックグラウンドで更新が非同期に発生します。

まず、JSONまたはXMLを使用してサーバーとハンドセットのデカップリングを行うことを強くお勧めします。あるテクノロジにロックすると、プラットフォームに関係なく同じテクノロジを使用する必要があるため、常に問題が発生します。つまり、他のプラットフォーム（Web、iOSなど）に拡張する予定がある場合は、サーバーによって指示された形式を使用する必要があります。一般的なフォーマットを選択すると、長期的にはそれが簡単になります。現実には、公共図書館の読書/書記の量は些細なことです。

データの同期には2通りの方法があります。

1. AlarmManager

我々は（6時間ごとを言うことができます）、定期的にウェイクアップするためのサービスをトリガするAlarmManagerをスケジュールします。ウェイクアップは、サーバーに接続するバックグラウンドサービスを開始し、JSONで変更をダウンロードし、ローカルのSQLite DBを更新します。接続がない場合、更新はスキップされ、次の起床のためにスケジュールされます。接続の復元時に自動的に同期を再開するConnectivityChangedレシーバーを追加します。

2. GCM

それはもう少し作業だが、変更があるときにのみ、ローカルデータベースを更新した場合、バッテリーとデータ使用量の節約。 Google Cloud Messagingは、デバイスにウェイクアップメッセージを送信し、同期サービスを開始するように通知することができます。同期サービスは、上記のAlarmManagerメソッドと同じように実行されます。

データを「新鮮」にする方法と変更頻度に応じて、上記の両方の方法を組み合わせて使用​​します。 RSSフィードのようなものは30分ごとに更新されるべきですが、気象データは4時間以上更新する必要はありません。

データベースの同期を実行するには、次のように入力します。

レシーバ - >システムイベントをリッスンし、サービス サービスをトリガ - > [JSONをダウンロードして、SQLiteのプロバイダに プロバイダを更新し、サーバーに接続 - >データベースにレコードを挿入し、ContentObservers ContentObserversへのコンテンツの変更をブロードキャスト - >アプリケーションが実行されているとき、ContentObserversは新しいデータでUIを更新します

上記の各コンポーネントには多くの技術的な詳細がありますが、サーバーデータをローカルと同期させるための非常に堅牢なアーキテクチャが必要ですdb。

Answer 2

私は同様の要件を持つプロジェクトに取り組んでいます。どこかのサーバーに大きなデータベースを用意し、そこからデータを取得するモバイルデバイスを使用したいと考えています。デバイスがオフラインになった場合は、自分でデータのコピーをローカルに保存しているので問題ありません。

サーバーテクノロジーとしてBigCouch（クラスタリングをサポートするApache CouchDbのfork）を使用し、モバイルデバイスでCouchbase Mobileを使用することに決めました。 （TouchBookのAndroid用TouchDBはCouchbase Mobileに取って代わりますが、まだ安定していません）

私たちがCouch *テクノロジーを使用した理由は、CouchがHTTP経由で良好な複製を行っているからです。プログラムによってモバイルデバイス上で同期イベントを開始すると、すべての挿入、更新、および削除がレプリケートされます。それはそれ自身の埋め込まれたCouchDbの情報をモバイルデバイスに保存するので、オフラインで読むことができます。

Couch道路を降りたくない場合は、SQLliteのようなものを使用してREST/API呼び出しの結果を保存するだけです。次に、モバイルデバイスがオフラインになってから復帰するときのための独自のレプリケーションロジックを作成する必要があります。これを行うための創造的な方法があります。多分それはオプションです。