Atlas での同期ストレージの最適化

項目一覧

履歴

削除
クライアントの最大オフライン時間
重要な概念
クライアントの最大オフライン時間は、クライアントのリセットにすぐには影響しません
クライアントの最大オフライン時間の設定
Flexible Sync を使用する際のパフォーマンスとストレージの最適化
概要

Atlas Device Sync、Atlas Edge Server、Data API、HTTPS endpoints は非推奨です。詳細については、の廃止ページを参照してください。

Atlas Device Sync は、アプリの同期された Atlas クラスター内のスペースを使用して、同期用メタデータを保存します。これには、同期された各データベースに対する変更の履歴が含まれます。 Atlas App Services は、Atlas クラスター内のこのスペース使用量を最小限に抑えます。同期に必要な時間とデータを減らすには、メタデータを最小限に抑える必要があります。

履歴

App Services バックエンドは、 MongoDB oplog と同様に、各 Realm の基礎データに対する変更の履歴を保持します。App Services はこの履歴を使用して、バックエンドとクライアント間でデータを同期します。 App Services は同期された Atlas クラスターに履歴を保存します。

削除

アプリでクライアントの最大オフライン時間を設定すると、削除によって、クライアントの最大オフライン時間よりも古い変更が削除されます。

クライアントの最大オフライン時間

削除に使用されるクライアントの最大オフライン時間は、履歴の経過時間制限を制御します。これにより、クライアントがバックエンドとの同期セッション間でオフラインを維持できる期間が間接的に変更されます。指定された日数を超えて同期されなかったクライアントは、次にバックエンドに接続するときにクライアントがリセットされる可能性があります。

クライアントの最大オフライン時間の値が低く設定すると、同期に必要な履歴量が減ります。結果として得られる最適化により、同期された Atlas クラスターのストレージ使用量が削減されます。

新しいアプリでは、クライアントの最大オフライン時間がデフォルト値 30 日で自動的に有効になります。

警告

クライアントの最大オフライン時間による履歴の永続的な変更

クライアントの最大オフライン時間により、古い履歴の削除が可能になります。これにより、影響を受けた履歴が永続的に変更され、将来的にクライアントがリセットされる可能性があります。

重要な概念

同期は、すべてのクライアントで常に同じ終了状態にコンフィギュレーションする必要があります。同期中に回復するには、クライアントは最後の同期の直後から始まる変更の完全な履歴が必要です。クライアントが長期間同期されない場合、削除によって履歴が変更され、クライアントの変換が妨げられる可能性があります。同期は共通の結果に変換されるすべてのクライアントに依存するため、そのようなクライアントは同期できません。

そのため、クライアントが同期を再開する前に、クライアントリセットを完了する必要があります。クライアントリセットシナリオでは、クライアントは Realm のクライアントローカルコピーを削除し、バックエンドからその Realm の現在の状態をダウンロードします。その後、同期は Realm の新しいコピーの使用を再開します。

クライアントの最大オフライン時間は、削除を適用するまでのバックエンドの待機時間を制御します。指定された日数が同期なしで経過すると、クライアントは次にバックエンドに接続するときにクライアントリセットを発生させる可能性があります。

クライアントの最大オフライン時間を指定しないアプリケーションは、削除を適用しません。つまりクライアントは、数週間、数か月、あるいは年など、任意の期間オフラインになった後に接続し、変更を同期することができます。頻繁に編集される Real では、時間の経過とともに多くの変更が蓄積されます。大規模な変更セットでは、同期に必要な時間とデータ使用量が増えます。

クライアントの最大オフライン時間は、クライアントのリセットにすぐには影響しません

削除すると、履歴が永続的で元に戻らない変更が生じます。その結果、クライアントの最大オフライン時間を増やしても、クライアントがクライアントリセットを受信するまでの時間の長さはすぐには変わりません。既存の履歴は削除によってすでに変更されているため、クライアントをリセットする必要があります。新しい履歴には、新しいクライアントの最大オフライン時間まで累積時間が必要です。

クライアントの最大オフライン時間を短縮しても、クライアントがクライアントをリセットするまでの時間の長さはすぐには変わりません。定期的にスケジュールされた削除ジョブが新しく適格な履歴に削除を適用すると、クライアントリセットは早期に実行され始めます。

クライアントの最大オフライン時間の設定

App Services UI から、サイドバーの [ Device Syncメニューをクリックします。 Dashboardタブはデフォルトで表示されます。
[Configuration] タブをクリックします。
[ Advanced Configuration (optional) ] セクションまで下にスクロールし、[] ドロップダウンをクリックしてセクションを展開します。
Client Max Offline Timeセクションで、アプリケーションのクライアントの最大オフライン時間の数を指定します。デフォルト値は30日です。の最小値は1です。
保存する準備ができたら、画面の下部にある [ Save Changes ] ボタンをクリックします。
確認ウィンドウで、 Save Changesボタンを再度クリックして変更を確定します。

次のプルコマンドを使用して、アプリの最新バージョンのローカルコピーを取得します。
プル
```
appservices pull --remote="<Your App ID>"
```
アプリのsync/config.jsonファイルの client_max_offline_daysプロパティを使用して、アプリケーションのクライアントの最大オフライン時間数を設定できます。
``sync/config.json``
```
{
   "client_max_offline_days": 42,
}
```
次のプッシュコマンドを使用して更新されたアプリ構成を配置します。
プッシュ
```
appservices push --remote="<Your App ID>"
```

Flexible Sync を使用する際のパフォーマンスとストレージの最適化

Flexible Sync 構成の場合、使用される Atlas ストレージ領域の量は、設定したクエリ可能なフィールドの数に直接比例します。クエリ可能なフィールドは、バッキング Atlas クラスターのストレージを使用します。設定するクエリ可能なフィールドが多いほど、バッキングクラスターで使用するストレージも多くなります。

アプリ内に多数のコレクションがある場合は、複数のコレクション間で同じクエリ可能なフィールド名を使用する必要がある場合があります。これを権限と組み合わせることで、どのコレクションが誰にアクセスできるかをより細かく制御できます。

例

アプリには 20 または 30 のコレクションが含まれている場合がありますが、クエリ可能なフィールドの数は最小限に抑える必要があります。すべてのコレクションのオブジェクトを同期するために、コレクション間でグローバルクエリ可能なフィールドを再利用できます。たとえば、 owner_idは複数のコレクションでクエリを実行したいフィールドとなる可能性があります。

あるいは、複数のコレクションにowner_idが存在しても、クエリは 1 つのコレクションでしか必要ありません。この場合は、 owner_idをコレクションのクエリ可能なフィールドにできます。つまり、Sync は、このフィールドでクエリを実行していないすべてのコレクションのメタデータを保存する代わりに、このフィールドに関するメタデータを 1 件のコレクションに対してのみ保持するだけで済みます。

最後に、デバイスがデータの特定のファセット（ owner_id == user.idなど）をクエリする必要があるアプリの場合は、フィールドをインデックス付きクエリ可能なフィールドに指定することをお勧めします。インデックス付きのクエリ可能なフィールドにより、クライアントがデータの小規模なサブセットのみを同期する必要があるアプリ（店舗のグループや単一ユーザーなど）のパフォーマンスが向上します。

アプリごとに 1 つのインデックス付きクエリ可能なフィールドを持つことができます。インデックス付きクエリ可能なフィールドは、同期する各コレクションに存在し、同じ適格なデータ型を使用する必要があるグローバルクエリ可能なフィールドです。

詳細については、「クエリ可能なフィールドの範囲」と「インデックス付きのクエリ可能なフィールド」を参照してください。

最高のパフォーマンスを得るには、広範なクエリを使用して同期された Realm を開きます。次に、より洗練されたクエリを追加して、クライアントアプリケーション内の対象を絞ったデータセットを公開します。広範なクエリからワーキングセットをスライスすると、より粒度の高いクエリを使用して複数の同期された Realm を開くよりもパフォーマンスが向上します。

クエリ可能なフィールドを設定するときは、Sync に使用するグローバルクエリを検討して、それらの集約クエリをサポートするフィールドを選択します。

例

ToDo リストアプリでは、同期クエリにassignee == currentUserやprojectName == selectedProjectなどのブロードキャストクエリが優先されます。これにより、ドキュメントを同期するフィールドがいくつかできます。クライアントでは、特定の優先順位や完了ステータスのタスクなど、ワーキングセットをスライスするためにクエリをさらに絞り込むことができます。

概要

Device Sync は、同期された Atlas クラスター内のスペースを使用して変更履歴を保存します。
Triggers を使用すると Flexible Sync アプリのスペース使用量は削減されますが、クライアントの最大オフライン時間（日数）を超えてバックエンドに接続されていないクライアントは、クライアントがリセットされる可能性があります。
柔軟な同期構成にクエリ可能なフィールドを追加すると、Atlas クラスターで消費されるストレージが増加します。ブロードキャストクエリを使用し、ブロードキャストクエリをサポートするフィールドの数を少なくすると、ストレージの消費量が削減されます。

戻る

本番負荷テスト

Atlas ボリュームの圧縮