スマートデバイスのオフライン同期の細分化された選択肢

ここでは、スマートデバイス用オフラインアプリケーションのアーキテクチャでオフライン同期を使用する際の選択肢について、対応する受信粒度基準別に説明します。このような場合、開発者は、主に 2 つのオプションのいずれか (テーブル単位または行単位) を使用して、サーバー側からテーブルのデータをデバイス (クライアント側) に同期できます。後者のオプションでは、ハッシュまたはタイムスタンプのいずれかを基準にすることもできます。
ここでは、簡略化のため、オフラインデータベースオブジェクトの条件を満たす行を単に「行」と呼んでいます。

テーブル単位での同期

同期対象のテーブルごとに、テーブルが変更された場合は、すべてのテーブルレコードがサーバーからデバイスに送信されます。
デバイスでは、変更されたテーブルごとに、すべてのテーブルレコードが削除され、サーバーから取得した新しい値がすべて保存されます。前回同期してからテーブルが変更されていない場合は、処理が行われません。
このメカニズムにより、サーバーで必要な処理は大幅に削減されます (テーブルのレコードを比較する必要がないため) が、データ転送は大幅に増加します。

方法

テーブル単位での同期のメカニズムを有効にするには、オフラインデータベースオブジェクトの [ Data Receive Granularity ] プロパティで値に「By Table」を選択します。

利点

このアルゴリズムは、テーブル内の行が少ない場合に役立ちます (そうでない場合、同期のたびに膨大な行がデバイスに転送されます)。
このソリューションを使用すると、各行のハッシュの計算コストが不要になります。

欠点

このソリューションでは、数行しか変更されていなくても、毎回すべての行が転送されます。

ハッシュに基づく行単位での同期

同期対象のテーブルごとに、テーブルが変更された場合は、変更 (つまり、挿入、更新、削除) された行のみがサーバーからデバイスに送信されます。差異は行のハッシュに基づいて計算されます。
このメカニズムを使用可能にするには、いくつかの補助テーブルをサーバーに作成し、既存のレコードの MD5 ハッシュを計算して、新規レコード、更新済みレコード、および削除済みレコードを検出できるようにする必要があります。サーバーでより多くの処理が必要になりますが、データトラフィックを大幅に削減できます。

方法

ハッシュを使用した行単位での同期のメカニズムを有効にするには、オフラインデータベースオブジェクトの [ Data Receive Granularity ] プロパティで値に By Row (既定値) を選択します。

アルゴリズム

ハッシュに基づく同期のアルゴリズムは、(各デバイス上の各テーブルに対して) 次のように動作します:

デバイスを初めて同期する場合は、次の処理を行います:
1. 同期が必要な行 (すべてのテーブルレコードをオフラインデータベースオブジェクトの状態に基づいてフィルタしたもの) を判別し、結果セットのハッシュを計算して、そのハッシュ (識別子として使用) とともにデバイスにデータを送信します。
2. また、結果セットの各行のハッシュを計算して、結果セットのハッシュ (デバイスに送信された識別子) および行の主キーとともに同期専用テーブルに格納します。
新たに同期する場合は、デバイスからサーバーにテーブルのハッシュ (前回の同期で受信した識別子) を送信し、サーバーで次の処理を行います:
1. (クエリでデータベースを照会し、条件を適用することによって) デバイスで必要な行を判別します。
2. 結果セットのハッシュを計算します。
3. このハッシュがデバイスから送信されたハッシュと一致する場合は、テーブルが変更されていないことを意味します。この場合、さらなるアクションは不要で、アルゴリズムはここで終了します。
4. ハッシュが一致しない場合は、結果セットの各行のハッシュを計算し、同じ行の前回同期時のハッシュと比較します。その後、次の処理を行います:
  1. ハッシュが一致する行は変更されていないため、デバイスに送信する必要はありません。
  2. ハッシュが一致しない行は変更されているため、更新として送信します。
  3. 前回の結果セットに存在しなかった行は、挿入として送信します。
  4. 前回の結果セットに存在していたが、今回存在しない行は、削除として送信します。
5. 新しいテーブルのハッシュは、行のハッシュおよび行の主キーとともにサーバーに格納され、次回の同期のときに使用されます。

利点

このアルゴリズムには、他のソリューションと比較していくつか利点があります。この方法を実装する主な理由の 1 つは、モデルのテーブルの変更を回避できることです。ハッシュを計算し、それをナレッジベースのデータモデルの外部に格納すれば、既存のテーブルを変更する必要がなくなります。
このアルゴリズムのもう 1 つの強みは、データベースがどのような方法で変更されたかに関係なく、適切に動作することです。同期が実行された時点で、基本的にはデータベースの現在のスナップショットを使用してハッシュが計算されます。データベースが現在の状態になった過程は問いません。

欠点

このアルゴリズムの主な欠点は、データセットが大きすぎるとパフォーマンスが低下することです。特に、ごくまれにしか変更が発生しない場合や同期の頻度が非常に高い場合などが当てはまります。これは、同期を実行するたびに、各行のハッシュを新しいデータセットで計算する必要があるためです。この処理には長時間かかることがあるため、すべてのシナリオに適したソリューションとは言えません。

タイムスタンプに基づく行単位での同期

タイムスタンプに基づく同期のアルゴリズムでは、異なるアプローチが使用されます。行単位での同期であることに変わりはありませんが、ハッシュに基づく差異の計算は行われません。
そのため、このアルゴリズムを使用する場合は、Last Modified Date Time Attribute および Logically Deleted Attribute の 2 つの項目属性を追加する必要があります。
このアルゴリズムはテーブルごとに適用できます。タイムスタンプに基づく同期のアルゴリズムとハッシュに基づく同期のアルゴリズムをテーブルに応じて使い分けることができます。

方法

タイムスタンプを使用した行単位での同期のメカニズムを有効にするには、まず、オフラインデータベースオブジェクトの [ Data Receive Granularity ] プロパティで値に By Row (既定値) を選択します。
さらに、タイムスタンプで同期するテーブルごとに、次に示すトランザクションレベルのプロパティで [ Last Modified Date Time Attribute ] および [ Logically Deleted Attribute ] を指定します。

アルゴリズム

サーバーに初回の同期リクエストが届くと、それに応じて、オフラインデータベースオブジェクトで指定された条件と一致するすべてのテーブルデータが、同期のタイムスタンプとともにデバイスに送信されます。
このタイムスタンプはデバイスに格納され (デバイスでは単なる識別子として扱われます)、次回の同期でサーバーに送信するときに使用されます。
次回の同期時には、デバイスからサーバーにタイムスタンプが送信され、そのタイムスタンプと [ Last Modified Date Time Attribute ] の値が比較されます。前回の同期以降に変更または追加されたすべての行が考慮されます。
これらの各行に対して次の処理が行われます:
1. [ Logically Deleted Attribute ] の値が True である場合、行は削除として送信されます。
2. その後、オフラインデータベースオブジェクトの条件が適用され、次の処理が行われます:
  1. 条件と一致するレコードは更新として送信されます (デバイスでは upsert として扱われます)。
  2. それ以外のレコードは削除として送信されます。

検討事項

このアルゴリズムは「変更タイムスタンプ」を使用するため、変更が発生するたびにこのタイムスタンプを更新する必要があります。このアクションは、開発者が責任を持ちます。レコードが変更されても、この値が更新されていなければ、アルゴリズムによって同期されることはありません。また、削除は論理的である必要があります。レコードをテーブルから物理的に削除してしまうと、アルゴリズムで検出できなくなり、デバイスから削除できなくなります。開発者は、レコードの削除を禁止し、論理的に管理する必要もあります。

制限事項

開発者による項目属性の管理

[ Logically Deleted Attribute ] プロパティおよび [ Last Modified Date Time Attribute ] プロパティの管理は開発者が行います。これらが正しく維持されていないと、アルゴリズムが想定どおりに動作しなくなります。

論理的な削除の必要性

このアルゴリズムは、ハッシュに基づく同期のアルゴリズムと異なり、削除された行の追跡は行いません。したがって、レコードをテーブルから削除してしまうと、情報が失われ、デバイスから削除できなくなります。

参照先テーブル

同期対象のテーブルの中には、別のテーブルで外部キーによって参照されているものがあります。タイムスタンプに基づく同期のアルゴリズムは、このようなテーブルには使用できません。
例として、Country テーブルを参照する Customer テーブルについて考えてみましょう。Country テーブルはスマートデバイスのアプリケーションでは使用されておらず、Customer の詳細に国名を表示する目的でのみ使用されています。この場合、Country の中でデバイスと同期されるのは、Customer で参照されているレコードのみになります。デバイスで必要なレコードセットは、Country テーブルではなく、Customer テーブルによって決まります。別の国に属する新しい顧客を追加した場合、変更日に関係なく、その国レコードをデバイスに送信する必要があります。これを自動的に処理するには、参照先テーブルをハッシュに基づいて同期する必要があります。
つまり、参照先テーブルに対しては、たとえタイムスタンプが設定されていたとしても、タイムスタンプメカニズムを使用することはできません。このような場合、参照先テーブルは、同期日に関係なく、ハッシュに基づく既定のメカニズムを使用して同期されます (もちろん利点/欠点はあります)。その根本的な理由は、参照先テーブルの状態が変わる可能性があり、タイムスタンプに基づいて同期されるテーブルに表示される拡張データにその状態を反映する必要があるためです。

レコードの変更を伴わない状態の変化

参照先テーブルの制限は、同期対象のテーブルに含まれていないデータによってテーブルレコードの状態が変わる特殊なケースに関するものです。そのほかにも該当するケースがあります。
あるアプリケーションでは、Customer テーブルと Invoice テーブルを取り扱うとします。過去 30 日以内に請求書が発行された顧客をアクティブと定義して、アクティブな顧客のみをデバイスに同期するものとします。
この場合、Customer テーブルに対してタイムスタンプに基づく同期のアルゴリズムを使用することはできません。同期対象のレコードがテーブルのレコードの変更なしで変わる可能性があるためです。事実、この例では、現在の日時に応じて状態が変わるため、同期対象のレコードはデータベースの変更なしで変わることになります。

注

タイムスタンプに基づく同期は、GeneXus 15 Upgrade 8 以降で使用できます。