モバイルアプリのデータ同期-複数のデバイス、複数のユーザー

初めてのモバイルアプリの構築を検討しています。アプリケーションのコア機能の1つは、複数のデバイス/ユーザーが同じデータにアクセスできることです。すべてのデバイス/ユーザーはCRUD権限を持ちます。

アーキテクチャには、すべてのデータが保存されている中央サーバーが必要だと思います。デバイスはAPIを使用してサーバーと対話し、データ操作（レコードの追加、レコードの編集、レコードの削除など）を実行します。

データの同期が問題になるシナリオを想像します。アプリケーションがインターネットに接続されていないときに機能する必要があるため、この中央サーバーと通信できないと想定します。そう：

1. ユーザーAはオフラインで、レコード＃100を編集しています
2. ユーザーBはオフラインで、レコード＃100を編集しています
3. ユーザーCはオフラインで、レコード＃100を削除します
4. ユーザーCがオンラインになります（おそらく、レコード＃100がサーバー上で削除されるはずです）
5. ユーザーAとBはオンラインになりますが、編集したレコードはもう存在しません

上記に類似したあらゆる種類のシナリオが考えられます。

これは一般的にどのように処理されますか？私はMySQLを使用する予定ですが、そのような問題に適切でないのではないかと思っています。

現在、まったく同じ要件と問題を抱えたモバイル/デスクトップ/分散アプリで作業しています。

まず、これらの要件はモバイルアプリ自体に固有のものではなく、非接続/分散型のクライアントサーバートランザクション（並列プログラミング、マルチスレッド、要点）に固有のものです。それ自体はもちろん、モバイルアプリで対処する典型的な問題です。

一般に、これがすべて要約すると、n個のクライアントに配布される潜在的なデータレコードがあり、それらのクライアントが同時に編集する可能性があるということです。必要なのは

1. 適切なバージョン管理/ロック機構、
2. 適切な権利/アクセス管理、
3. 適切な同期/キャッシュ戦略

（1）には、いくつかのパターンを適用できます。2つの頻繁に使用されるロック戦略があります：Optimistic Offline Lockingと Pessimistic Offline Lockingです。これらのいくつかは、レコードが変更されるたびに更新されるすべてのデータレコードにカウンター（非常に単純な「タイムスタンプ」の一種）を使用するMultiVersion Concurrency Control（MVCC）など、異なるバージョン管理「パターン」で適用されます。。

（2）と（3）はそれ自体非常に広範な問題であり、（1）とは別に対処する必要があります。私の経験からのアドバイス：

• ほとんどの問題を抽象化するクライアントサーバー技術を使用してください。（1）Optimistic Offline Locking + MVCCを介して、（2）Web APIを介して、（3）Httpキャッシングを非常にうまく処理するCouchDbなどのWebテクノロジーを強くお勧めします。

• 実績のある技術とアプローチに頼ることができるなら、自分で物事を発明しないようにしてください。既存のテクノロジー/パターンの調査と比較に費やした時間は、独自のシステムを実装しようとするよりもはるかに優れていると思います。

• 可能であれば、同種の技術を使用してください。「同種」とは、同じ原則を念頭に置いて構築された技術、たとえばWeb 2.0の使用シナリオを意味します。例：ローカルキャッシュ戦略で適切なCouchDbおよびRESTクライアント（Web API）を使用することは、モバイルアプリにSQLを使用するよりも良い選択です。

• MySQLはこのような使用シナリオ向けに明示的に作成された技術ではないため、MySQLの使用には強くお勧めします。動作しますが、すでにWeb通信と同時実行スタイル（多くのNoSQLデータベースなど）を採用しているデータベースシステムの方がはるかに優れています。

ところで、私はCouchDb APIに対して動作するカスタムローカルクライアントでCouchDbに落ち着きました。私はMSQL +（N）Hibernateの使用から切り替えて、そもそも正しい選択を行わなかった（十分な調査を行っていないことを意味する）ために高い代償を払った。

最初に、APIとデータベース（MySQL）の両方に言及しました。APIを使用し、データベース間で直接通信しようとしないことを強くお勧めします。後者のルートは、まったくうまくスケールしません。

考慮すべき良い出発点の1つは、Apache CouchDBを使用することです。HTTPとJSONに基づいたスキーマレスであり、非常に優れた複製メカニズムを備えています。同様の問題を解決するために使用します。

CouchDBの複製メカニズムは、他のクライアントが使用するものと同じHTTP APIを使用します。したがって、本質的には、APIを介したレプリケーションを提供します。

iOSの場合、Couchbase Liteプロジェクトを使用することをお勧めします。データの同期には非常に有効です。Androidの場合、前述のCouchbase Liteプロジェクトを作成しているのと同じ会社が、同様の製品であるCouchbase Lite for Androidに取り組んでいます。iOSバージョンほど完全ではなく、達成するための作業が残っています。

ただし、CouchDBで考慮すべき点がいくつかあります。

1. 独自の競合解決を提供する必要があります。幸いなことに、競合が発生した場合、CouchDBは競合するバージョンを保持し、メインバージョンとして保持するために決定的かつ任意の競合を選択します。したがって、初期バージョンの競合解決を遅らせることを検討できます。
2. 複製メカニズムは、データベース自体を複製するために作成されており、それ自体は同期されていません。そのため、削除されたドキュメントが多数ある場合、サーバーからクライアントへの複製に時間がかかります。「データベースの回転」を使用してこれを回避する方法があります。これは本質的に古い削除を削除します。
3. レプリケーションの順序を制御することはできません。ただし、フィルター処理されたレプリケーションを使用して最初にドキュメントを取得したり、オンデマンドでサーバーに直接アクセスしたりするなど、レプリケーションのパフォーマンスを向上させるための巧妙なソリューションを作成できます。
4. iOSではバックグラウンドで複製は行われません。iOS SDKを使用して、バックグラウンドレプリケーションのいくつかのケースを提供できます。

最後に、CouchDBを使用したくない場合は、少なくともHTTP APIを使用して同期アルゴリズムを作成する方法の良いリファレンスとして使用できます。私の提案は、CouchDBから始めて、さらにカスタムが必要な場合は、独自のロールを検討することです。