同期設定

項目一覧

利用可能な設定

同期するクラスター
同期タイプ
開発モード
データベース名（開発モードのみ）
クエリ可能なフィールド
権限
Data Ingest
クライアント最大オフライン時間
クライアントリカバリ
同期構成ファイルの参照
同期構成オブジェクト

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

このページでは、 Device Sync を有効または構成するときに使用できる設定について説明します。

利用可能な設定

同期するクラスター

同期されたデータを保存するリンクされた Atlas クラスターデータソースの名前。

Device Sync が有効になっている間は、このフィールドを変更できません。別のクラスターを選択する前に、同期を終了する必要があります。

注意

Device Sync のデータソース要件

Device Sync を有効にするには、App Services App に次の要件を満たすリンクされたデータソースが少なくとも 1 つ必要です。

MongoDB 5.0以降を実行しているシャーディングされていない MongoDB Atlas クラスター。
クラスターは、サーバーレスインスタンスまたはフェデレーティッドデータベースインスタンスにはできません。「データソースの制限」を参照してください。

同期タイプ

重要

同期タイプはパーティションベースの同期アプリでのみ使用可能

アプリの同期タイプを選択する機能は、プロジェクト内に少なくとも 1 つの既存のパーティションベースの同期アプリがある組織でのみ使用できます。

パーティションベースの同期は非推奨となり、新しい同期構成では許可されなくなりました。代わりに、すべての新しい同期構成は自動的に推奨される Flexible Sync モードになります。

Device Sync を有効にすると、次のいずれかの同期モードを選択できます。

Flexible Syncを使用すると、クライアント内でクエリを定義し、クエリに一致するオブジェクトのみを同期できます。クライアント側サブスクリプションを使用すると、クライアントアプリケーションは次のことが可能になります。
- クエリを維持する
- Reactに対応する
- クエリを追加、変更、削除する
Flexible Sync は、新しい同期構成で使用できる唯一のモードです。
パーティションベースの同期は、非推奨となり、新しい同期構成では許可されていない古い同期モードです。
古いパーティションベースの同期をすでに使用している既存のアプリがある場合は、Flexible Sync に移行することを強くお勧めします。移行は自動プロセスであり、SDK のバージョンをアップグレードする場合を除いて、クライアントアプリコードを変更する必要はありません。詳細については、「 Device Sync モードの移行」を参照してください。

Device Sync が有効になっている間は、同期タイプを変更できません。変更を行う前に、同期を終了または一時停止する必要があります。

開発モード

開発モードは、Device Sync がクライアント側のデータモデルに基づいてスキーマを推論および更新できるようにする構成設定です。開発が効率化されますが、本番環境では使用しないでください。

開発モードでは、クライアントアプリケーションコードで直接スキーマを設計できるため、開発を迅速化します。

Realm を同期すると、Atlas App Services は同期されたすべてのオブジェクトタイプを、データベース名（開発モードのみ）で指定されたデータベース内の独自のコレクションにマッピングします。クライアント側でオブジェクトモデルを更新すると、App Services はコレクションスキーマを一致するように更新します。これにより、アプリの開発に伴うクライアントコード内のオブジェクトを更新できます。

開発モードではデータアクセスルールを使用できます。スキーマの変更はデータアクセスルールを無視することに注意してください。つまり、どのクライアントでも、クライアントモデルを変更してバックエンドスキーマを更新できます。

開発モードを使用するときに Realm オブジェクトスキーマが App Services スキーマにマッピングする方法の詳細については、「データモデルマッピング」を参照してください。

同期されたオブジェクトスキーマの変更の詳細については、「データモデルの更新」を参照してください。

重要

本番アプリの開発モードを無効化

開発モードは、本番環境での使用に適していない開発ユーティリティです。アプリを本番環境でアクセスできるようにする前に、必ず開発モードをオフにしてください。

重大な変更

2023 年 9 月 13 日以降に作成された開発モードの App Services アプリは、クライアントコードから同期されたオブジェクトスキーマに重大な変更を加える可能性があります。

アプリが 2023 年 9 月 13 日より前に作成された場合は、サポートに問い合わせて、この機能を有効にできます。

前提条件

2023 年 9 月 13 日以降に作成された App Services App
Flexible Sync との互換性を備えた MongoDB 5.0 以降
SDK の最小バージョン:
- Realm C++ SDK v1.0.0
- Realm Flutter SDK v1.6.0
- Realm Java SDK v10.16.2
- Realm Kotlin SDK v11.1.1
- Realm .NET SDK v11.6.0
- Realm Node.js SDK v12.2.0
- Realm React Native SDK v12.2.0
- Realm Swift SDK v10.42.2

注意

2023 年 9 月 13 日より前に作成されたアプリ

2023 年 9 月 13 日より前に作成されたアプリの場合は、App Services UI でオブジェクトスキーマを更新する必要があります。詳細については、「データモデルの更新」を参照してください

クライアントコードから重大な変更を行うには、次の手順に従います。

ローカル Realm とデータを削除します。これは、バックエンドに同期されたデータには影響しません。同期されていないローカル変更は削除され、回復できなくなります。
ローカルオブジェクトモデルを変更します。
更新したオブジェクトモデルを使用してRealmを開きます。
クライアントアプリを実行して、変更をバックエンドに同期します。

Realm ファイルを削除するには、Realm SDK 固有のメソッドを使用します。

開発モードを有効にすることによる副作用

開発モードを有効にすると、次の 2 つの副作用があります。

有効化 匿名認証。
無効化 配置案。

アプリに匿名認証が必要ない場合は、開発モードを有効にした後に無効にすることをお勧めします。

開発モードが無効になるまで、UI で配置案を再度有効にすることはできません。ただし、 CLI または Admin API を使用して配置案を手動で作成することはできます。

データベース名（開発モードのみ）

開発モードを有効にする場合は、同期されたオブジェクトを保存するデータベースを指定します。 App Services は、同期されたオブジェクトのすべてのタイプに対して、この開発モードデータベースに新しいコレクションを作成します。

例

myappの開発モードデータベースを指定します。 iOS クライアントのモデルはPersonです。 Personオブジェクトのインスタンスを含む Realm を同期します。開発モードでは、モデルに関連付けられたサーバー側のスキーマが作成されます。オブジェクトはmyapp.Personコレクションに同期します。

Atlas App Services は、新しいオブジェクトタイプごとに新しいサーバー側スキーマとコレクションを引き続き作成します。後でDogオブジェクトを追加すると、そのオブジェクトは Atlas App Services によって作成される新しいmyapp.Dogコレクションに同期されます。

クエリ可能なフィールド

Flexible Sync を構成するときは、クライアントアプリケーションが Flexible Sync サブスクライブでクエリできるフィールド名を指定します。サブスクライブクエリで使用できるフィールドは、クエリ可能なフィールドと呼ばれます。

例

ToDo リストアプリでは、クエリ可能なフィールドとしてassigneeまたはownerを設定できます。次に、クライアント側で、 assigneeまたはownerがログインしたユーザーに一致するタスクをクエリできます。

クエリ可能なフィールドスコープ

クエリ可能なフィールドは、構成時に指定したスコープに適用されます。使用可能なスコープは次の 2 つです。

グローバルクエリ可能なフィールド: アプリのスキーマ内のすべてのコレクションにわたる範囲。
コレクションクエリ可能なフィールド: アプリ内の単一のコレクションにスコープが設定されています。

クエリ可能なフィールドを特定のコレクションにスコープ設定すると、Sync メタデータの保存に必要な Atlas ストレージの容量が減ります。

ルールと権限を使用して、コレクションごとにより詳細なアクセス制御を構成できます。グローバルフィールドとコレクションクエリ可能なフィールドの両方に対してコレクションレベルのルールと権限を定義できます。

クエリ可能なフィールドの設定

開発モードを有効にすることで、クエリ可能なフィールドを自動的に指定できます。開発モードの使用中にクライアントクエリに表示されるフィールドは、クエリ対象のコレクションのコレクションクエリ可能なフィールドとして自動的に追加されます。

指定するフィールド名は任意の文字列です。指定したフィールド名と一致するフィールド名を持つフィールド（かつ他の適格条件を満たす場合）、オブジェクトタイプにそのフィールドがある場合、そのフィールドは Device Sync でクエリで使用できるようになります。

インデックス付きクエリ可能なフィールドの設定

Device Sync が有効になっていない場合にのみ、インデックス付きのクエリ可能なフィールドを追加または削除できます。 Device Sync がすでにアプリで実行されている場合は、 Sync を終了し、再度有効にするときにインデックス付きクエリ可能なフィールドを構成する必要があります。

これにより、同期を再度有効にした後に再接続しようとするクライアントはクライアントがリセットされます。

適格なフィールドタイプ

Flexible Sync は、クエリ可能なフィールドとしてスカラー型を持つ最上位のプリミティブフィールドのみをサポートします。また、これらのプリミティブの配列をクエリ可能なフィールドとして含めることもできます。 Flexible Syncでは、埋め込みオブジェクトまたはオブジェクトの配列をクエリ可能なフィールドとしてサポートしていません。

インデックス付きのクエリ可能なフィールドでは、データ型のサブセットがサポートされます。インデックス付きクエリ可能なフィールドは、 int64 、 string 、 ObjectId 、 UUIDのいずれかになります。

Tip

「 RQL - Flexible Syncの制限」も参照してください

これらのフィールドで実行できるクエリの詳細については、「 Flexible Sync RQL の制限」を参照してください。

予約されたフィールド名

App Services では、 RQLやその他の目的でいくつかのキーワードが予約されています。フィールド名として予約済みキーワードを使用することはできません。

App Services では、大文字と小文字が区別されない次のキーワードが予約されます。

および
asc
上昇
で始まる
間
に含まれる
desc
下降

distinct
で終了
false述語
inf
無限大
のように
limit

ナン
nil
null
or
sort
サブクエリ
true述語

例

フィールド名として、 descending 、 Descending 、 DESCENDING 、またはDeScEnDiNGを使用することはできません。

App Services では、指定された正確な大文字小文字を持つ次のキーワードも予約されます。

すべて
任意
B64
false
で
なし
ではない

ある程度
true
すべて
any
false
in

なし
ではない
oid
いくつかの
true
uuid

例

trueまたはTRUEはどちらも大文字と小文字が明確に予約されているため、使用できませんが、フィールド名としてTrueまたはtRUEを使用できます。

パフォーマンスとストレージ

クエリ可能な各フィールドは、Atlas クラスターに追加のメタデータストレージを追加するため、書込みパフォーマンスを低下させる可能性があります。アプリケーションに必要な数のクエリ可能なフィールドを持ち、必要最小限のコレクション数にスコープを設定する必要があります。

多くのアプリは、ストレージ使用量とクエリの柔軟性のバランスが適切であり、クエリ可能なフィールドは単一のコレクションに最大 10 個が適用されます。たとえば、グローバルクエリ可能なフィールドが 3 つ、コレクションクエリ可能なフィールドが 7 個ある場合、コレクションに適用されるクエリ可能なフィールドは 10 個あります。

1 つのコレクションにのみクエリしたいフィールドがあり、それがグローバルクエリ可能なフィールドとして構成されている場合は、Atlas のストレージ容量が不必要に消費されます。たとえば、すべてのコレクションにuserフィールドがあるが、1 つのコレクションの同期クエリにのみ使用する場合は、そのフィールドをコレクションクエリ可能なフィールドとしてスコープ設定することで、ストレージ要件が軽減されます。範囲を縮小すると、 userフィールドをクエリしていない他のコレクションの、Sync はそのフィールドのメタデータを保持する必要がなくなります。

ストレージ使用量を減らしたりパフォーマンスを向上させたりする必要がある場合は、アプリから不要なクエリ可能なフィールドを削除できます。ただし、クエリ可能なフィールドを追加または削除することの影響に注意してください。詳細については、「クエリ可能なフィールドの追加または削除に関する結果」を参照してください。

その他の考慮事項については、「 Flexible Sync を使用する際のパフォーマンスとストレージの最適化」を参照してください。

インデックス付きクエリ可能なフィールド

インデックス付きのクエリ可能なフィールドを追加すると、特定のタイプのワークロードのパフォーマンスを向上させることができます。 インデックス付きクエリ可能なフィールドは、より効率的にクエリを実行でき、同期パフォーマンスが向上するグローバルなクエリ可能なフィールドです。 1 つのグローバルクエリ可能なフィールドをインデックス付きクエリ可能なフィールドとして指定できます。

クエリ可能なフィールドをインデックス化すると、 {“store_id”: 1}や{“user_id”: “641374b03725038381d2e1fb”}などの単一フィールドに対する単純なクエリのパフォーマンスが向上します。

インデックス付きクエリ可能なフィールドは、すべての同期コレクションのスキーマに表示され、同じ有効なデータ型を使用する必要があります。たとえば、インデックス付きクエリ可能なフィールドがstore_idの場合、同期するすべてのコレクションに表示される必要があり、すべてのコレクションで有効なタイプである必要があります。適格なフィールドタイプの詳細については、「適格なフィールドタイプ」を参照してください。

クライアント上のインデックス作成されたクエリ可能なフィールド値は変更できません

インデックス付きクエリ可能なフィールドを構成すると、クライアントデバイスは既存のオブジェクトのインデックス付きクエリ可能なフィールド値を更新できません。たとえば、インデックス付きクエリ可能なフィールドがstore_idの場合、クライアントはこの値を直接変更できません。クライアントからの変更は、同じ時間枠でオブジェクトに行われる他のアップデートと競合する可能性があるため、サポートされていません。

デバイス上のインデックス付きクエリ可能なフィールドの値を変更しようとすると、それを修正する書込みエラーがトリガーされます。このエラーとそれに発生する動作の詳細については、 Flexible Sync エラーのドキュメントのErrorCompensatingWriteを参照してください。

この値は、Atlas データベースで直接変更することもできます。

警告

Atlas を通じてオブジェクトのインデックス付きクエリ可能なフィールド値を変更すると、オブジェクトに対する同時クライアント更新が上書きされる可能性があります。

インデックス付きクエリ可能なフィールドに対するクライアント側クエリ

アプリがインデックス付きクエリ可能なフィールドを使用する場合、Flexible Sync サブスクライブのクライアント側のクエリには、定数に対する==またはINの比較を使用して、インデックス付きのクエリ可能なフィールドを少なくとも 1 回含める必要があります。たとえば、 user_id == 641374b03725038381d2e1fbやstore_id IN {1,2,3}などです。

オプションとして、インデックス付きクエリ可能なフィールドが==またはINを少なくとも 1 回使用して定数と直接比較される限り、 AND比較を含めることができます。たとえば、 store_id IN {1,2,3} AND region=="Northeast"やstore_id == 1 AND (active_promotions < 5 OR num_employees < 10)などです。

インデックス付きクエリ可能なフィールドに対する無効なFlexible Sync クエリには、次のクエリが含まれます。

インデックス付きクエリ可能なフィールドは、クエリの残りの部分でANDを使用しません。 store_id IN {1,2,3} OR region=="Northeast"ORたとえば、AND はではなくを使用しているため無効です。同様に、 store_id == 1 AND active_promotions < 5 OR num_employees < 10は無効です。 ANDはクエリ全体ではなく、その横にあるタームにのみ適用されるためです。
インデックス付きクエリ可能なフィールドは等価演算子では使用されません。たとえば、 store_id > 2 AND region=="Northeast"は無効です。インデックス付きクエリ可能なフィールドでは>演算子のみが使用され、等価比較がないためです。
クエリに、インデックス付きのクエリ可能なフィールドが完全にありません。たとえば、 region=="Northeast"またはtruepredicateは、インデックス付きクエリ可能なフィールドが含まれていないため無効です。

クエリ可能なフィールドの追加または削除に関する影響

同期が有効になっているときに同期構成を更新して、クエリ可能なフィールド名を追加または削除できますが、次の点に注意してください。

クエリ可能なフィールドを追加すると、デバイスは、フィールドが追加されたDevice Sync 履歴の点での時点にデバイスが追いついた場合にのみ、そのフィールドで同期できます。

クエリ可能なフィールドを削除すると、そのフィールドをまだ使用しているデバイスは Device Sync セッションが削除され、クライアントリセットを実行する必要があります。削除されたフィールドを使用しないクライアントは、エラーを受け取りません。クエリ可能なフィールドを削除するときにクライアントリセットがトリガーされないようにするには、まずクライアント側でそのフィールドの使用を削除する必要があります。

クエリ可能なフィールドを追加または削除する前に同期を終了する場合、これらの考慮事項は適用されません。ただし、同期を終了すると、アプリと同期したすべてのクライアントのクライアントtrigger リセットがされます。

権限

Atlas Device Sync は、同期されたクラスターへのすべてのリクエストに対してロールベースのデータアクセスルールを強制します。ルールは、データの同期、表示、変更を行うユーザーの能力を決定する動的JSON 式です。

詳細については、「ロールベースの権限」を参照してください。

Data Ingest

Data Ingest は、クライアント側の挿入専用ワークロードを持つアプリケーション向けの同期戦略です。これは 1 つ以上のコレクションに対して有効にできます。 Atlas 時系列コレクションを含む任意のコレクションタイプへの書き込みをサポートします。

たとえば、センサーデータを頻繁にログに記録する IoT アプリには、書込みワークロードが重要ですが、読み取りワークロードはありません。デバイスが長時間オフラインになることもあります。 Data Ingest は、双方向同期に必要な処理の一部をバイパスし、Atlas コレクションへの書込み速度を大幅に向上させます。

他のユースケースには、小売アプリからの請求書やアプリケーションイベントのログ記録など、不変データの書き込みが含まれますが、いずれも競合の解決が必要です。

Data Ingest は個々のコレクションに適用できます。つまり、アプリは Data Ingest を使用していくつかのデータを書き込みますが、他のコレクションには双方向 Flexible Sync を使用してデータを書き込みます。

Data Ingest コレクションはデータの書き込み専用です。これらのコレクションに対して Flexible Sync クエリを使用することはできません。代わりに、「 MongoDB データソースへの接続」を使用します。

Data Ingest を有効にしたら、クライアント SDK を介してクライアントアプリに実装します。現在、次の Realm SDK は Data Ingest をサポートしています。

C++ SDK: Atlas へのストリームデータ - C++ SDK
Flutter SDK: Atlas へのストリームデータ - Flutter SDK
Kotlin SDK: Atlas へのストリームデータ - Kotlin SDK
.NET SDK:一方向データ取り込み - .NET SDK
Node.js SDK:非対称オブジェクトの定義
React Native SDK:非対称オブジェクトの定義
Swift SDK: Atlas へのストリームデータ - Swift SDK

Atlas Device Sync は、このデータのライフサイクルを完全に管理します。 Data Ingest 同期が完了するまでデバイス上に保持され、その後デバイスから削除されます。

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

[クライアント最大オフライン時間] は、同期セッション間でクライアントがオフラインになる時間を決定します。この値を変更すると、同期された Atlas クラスターで使用されるストレージとオフラインアクセスのバランスがとれます。詳細については、「クライアントの最大オフライン時間」を参照してください。

クライアントリカバリ

クライアントリカバリを使用すると、クライアントはデバイス上のデータを回復しながら、クライアントリセットの自動実行を試行できます。詳細については、「同期されていない変更の回復」を参照してください。

同期構成ファイルの参照

アプリケーションの同期構成ファイルは、エクスポートされたアプリのsyncディレクトリにあります。

app/
└── sync/
    └── config.json

たとえば、次の同期構成は、Flexible Sync を使用するアプリに適用されます。

sync/config.json

{
  "type": "flexible",
  "development_mode_enabled": <Boolean>,
  "service_name": "<Data Source Name>",
  "database_name": "<Development Mode Database Name>",
  "state": <"enabled" | "disabled">,
  "client_max_offline_days": <Number>,
  "is_recovery_mode_disabled": <Boolean>,
  "queryable_fields_names": [
    <Array of String Field Names>
  ],
  "indexed_queryable_fields_names": [
   <Array of String Field Names>
  ],
  "collection_queryable_fields_names": <Map[String][]String>
  "permissions": "<Deprecated, Do Not Use>"
}

非推奨のpermissionsフィールドが、エクスポートされたアプリの構成に引き続き表示される場合があります。これは、アプリが統合ルールシステムに自動的に移行していないことを示している可能性があります。アプリが移行されるまで、このフィールドを削除しないでください。

同期構成オブジェクト