パーティションベースの同期

項目一覧

重要な概念

重要な用語
パーティション
パーティションキー
パーティションキーの変更
パーティション値
パーティションベースの同期の有効化
始める前に
手順
パーティションベースのルールと権限
パーティションベースの同期ルールの動作
パーティションベースの同期権限
重要な概念
読み取り権限
書込み権限
権限戦略
グローバル権限
特定のパーティションに対する権限
特定のユーザーの権限
ユーザーデータに基づく権限
関数ルール
パーティションベースの同期ルールを App Services ルールに移行
パーティション戦略
Firehose 戦略
ユーザー戦略
チーム戦略
チャネル戦略
リージョン戦略
バケット戦略
Data Ingest
パーティションベースの同期構成
パーティションベースの同期構成を変更する
パーティションベースの同期エラー
バックエンド圧縮

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

Atlas Device Sync には、 Flexible Syncと古いパーティションベースの同期の 2 つの同期モードがあります。パーティションベースの同期は非推奨となり、新しい同期構成では許可されなくなりました。

このページの情報は、パーティションベースの同期を引き続き使用しているユーザー向けです。

注意

パーティションベースの同期から Flexible Sync への移行

パーティションベースの同期アプリを Flexible Sync に移行することをお勧めします。移行の詳細については、「 Device Sync モードの移行」を参照してください。

重要な概念

Flexible Sync では、同期されたクラスター内のドキュメントは、「パーティションキー」として指定されたフィールドの値が同じになることで「パーティション」を構成します。パーティション内のすべてのドキュメントには、特定のユーザーに対して同じ読み取り/書込み権限が付与されます。

ユーザーによるドキュメントの読み取りと書込みを決定する値を持つパーティションキーを定義します。 App Services は、ユーザーが特定のパーティションに対して読み取りまたは書込み可能であるかどうかを決定するために、一連のルールを評価します。 App Services は、パーティションを同期された個々の .realmファイルに直接マッピングします。同期された Realm 内の各オブジェクトには、パーティション内に対応するドキュメントがあります。

例

Flexible Sync を使用した在庫管理アプリケーションを検討します。パーティションキーとしてstore_numberを使用すると、各店舗は在庫に関連するドキュメントの読み取りと書込みができます。

このタイプのアプリの権限の例は次のとおりです。

{ "%%partition": "Store 42" }

店舗の従業員は、店舗番号が「店舗 42」であるドキュメントへの読み取りおよび書き込みアクセス権を持つことができます。

一方、カスタマーは、在庫を保存するための読み取り専用アクセス権を持つことができます。

クライアントでは、同期された Realm を開くときに、パーティションキーの値を渡します。次に、App Services は、パーティションキー値がクライアントアプリケーションから渡された値と一致するオブジェクトを同期します。

例

上記のストア在庫の例に基づいて、SDK は同期構成のpartitionValueとしてstore42を渡す場合があります。これにより、 partitionValueがstore42であった InventoryItem が同期されます。

カスタムユーザーデータを使用して、ログインユーザーが店舗の従業員であるか、顧客であるかを示すことができます。店舗の従業員にはstore42データセットの読み取りと書込み権限が付与され、カスタマーには同じデータセットに対する読み取り権限のみが付与されます。

const config = {
  schema: [InventoryItem], // predefined schema
  sync: {
    user: app.currentUser, // already logged in user
    partitionValue: "store42",
  },
};
try {
  const realm = await Realm.open(config);
  realm.close();
} catch (err) {
  console.error("failed to open realm", err.message);
}

Device Sync では、特定のバージョンの MongoDB を実行するために MongoDB Atlas クラスターが必要です。パーティションベースの同期には MongoDB 4.4.0 以降が必要です。

重要な用語

パーティション

パーティションは、同じパーティションキー値を共有するオブジェクトのコレクションです。

MongoDB Atlas クラスターは、複数のリモートサーバーで構成されます。これらのサーバーは同期されたデータ用のストレージを提供します。 Atlas クラスターはドキュメントをコレクションに保存します。各 MongoDB コレクションは、異なる Realm オブジェクトタイプにマップされます。コレクション内の各ドキュメントは、特定の Realm オブジェクトを表します。

同期された Realm は、デバイス上のローカルファイルです。同期された Realm には、エンドユーザーに関連する一部またはすべてのオブジェクトが含まれる場合があります。クライアントアプリは、アプリケーションが必要とするすべてのオブジェクトにアクセスするために、複数の同期された Realm を使用する場合があります。

パーティションは、Realm Database 内のオブジェクトを MongoDB 内のドキュメントにリンクします。同期された Realm ファイルを初期化すると、そのパラメーターの 1 つはパーティション値です。クライアントアプリは同期された Realm にオブジェクトを作成します。これらのオブジェクトが同期されると、パーティション値は MongoDB ドキュメントのフィールドになります。このフィールドの値によって、クライアントがアクセスできる MongoDB ドキュメントが決まります。

高レベルでは、次のことを行います。

パーティションは、同期されたクラスター内のドキュメントのサブセットにマップされます。
パーティション内のすべてのドキュメントには、特定のユーザーに対して同じ読み取り/書込み権限が付与されます。
Atlas App Services は各パーティションを個別の同期された.realmファイルにマッピングします。
同期された Realm 内の各オブジェクトには、パーティション内に対応するドキュメントがあります。

形状と色のグループを使用して分割を説明する図。 MongoDB コレクションはシェイプ別にグループ化され（オブジェクトタイプと同等）、Realm は色別にグループ化されます（パーティション値と同等）。

パーティションは、Atlas クラスター内のデータを形成します。各シェイプはオブジェクトタイプを表します。パーティションは、各シェイプのcolorによって決まります。

パーティションキー

パーティションキーは、 Atlas Device Sync を構成するときに指定する名前付きフィールドです。 Device Sync はこのキーを使用して、特定のドキュメントが含まれているパーティションを決定します。

データモデルとアプリの複雑さによって、パーティションキーは次のいずれかになります。

各ドキュメントにすでに存在し、データを論理的に分割するプロパティ。たとえば、すべてのドキュメントが特定のユーザーのみに公開されているアプリを考えてみましょう。ユーザーの ID 値をowner_idフィールドに保存し、それをパーティションキーとして使用できます。
データを分割するために作成する合成プロパティ（例: _partition ）。アプリに自然なパーティションキーが含まれていない場合は、これを使用できます。

オブジェクトでパーティションキーを必須または任意にすることができます。 App Services は、パーティションキーを含まないオブジェクトをデフォルトのパーティション（ null パーティション）にマッピングします。

パーティションキーを選択する際には、次の点を考慮してください。

パーティションキーは、 String 、 ObjectID 、 Long 、またはUUIDのいずれかのタイプでなければなりません。
App Services クライアントは、パーティション値を直接変更しないでください。クライアントが変更できるフィールドをパーティションキーとして使用することはできません。
パーティションキーは、同期されたすべてのドキュメントで同じフィールド名を使用します。パーティションキーは、あらゆるオブジェクトのモデル内のどのフィールド名とも重複してはなりません。

例

次のスキーマは、自然なパーティションキーと合成パーティションキーを示します。

owner_idフィールドはすでにアプリのデータモデルの一部であるため、自然キーです。
_partitionフィールドは、パーティションキーとして機能することのみを目的としているため、合成キーです。

アプリで指定できるパーティションキーは 1 つだけですが、ユースケースによってはどちらのフィールドも機能する可能性があります。

{
  "title": "note",
  "bsonType": "object",
  "required": [
    "_id",
    "_partition",
    "owner_id",
    "text"
  ],
  "properties": {
    "_id": { "bsonType": "objectId" },
    "_partition": { "bsonType": "string" },
    "owner_id": { "bsonType": "string" },
    "text": { "bsonType": "string" }
  }
}
{
  "title": "notebook",
  "bsonType": "object",
  "required": [
    "_id",
    "_partition",
    "owner_id",
    "notes"
  ],
  "properties": {
    "_id": { "bsonType": "objectId" },
    "_partition": { "bsonType": "string" },
    "owner_id": { "bsonType": "string" },
    "notes": {
      "bsonType": "array",
      "items": { "bsonType": "objectId" }
    }
  }
}

パーティションキーの変更

アプリのパーティションキーは、Sync 対応アプリのデータモデルの主要部分です。同期構成でパーティションキーを設定すると、そのキーのフィールドを後で再割り当てすることはできません。パーティションキーを変更する必要がある場合は、同期を終了する必要があります。その後、新しいパーティションキーを使用して再度有効にできます。ただし、これにはすべてのクライアントアプリケーションがデータをリセットして新しい Realm に同期する必要があります。

警告

同期終了後の同期の復元

Atlas Device Sync を終了して再度有効にすると、クライアントは同期できなくなります。同期を復元するには、クライアントがクライアントリセットハンドラーを実装する必要があります。このハンドラーは、同期されていない変更を破棄したり、回復を試行したりできます。

パーティション値

パーティション値は、特定のドキュメントのパーティションキーフィールドの値です。同じパーティション値を持つドキュメントは同じパーティションに属します。同じ Realm ファイルに同期し、ユーザーレベルのデータアクセス権限を共有します。

パーティションの値は、対応する同期された Realm の識別子です。パーティションの値は、クライアントで同期された Realm として開くときに指定します。 Atlas でパーティション値を変更すると、App Services はその変更を次の 2 つの操作として解釈します。

古いパーティションからの削除。
新しいパーティションへの挿入。

警告

ドキュメントのパーティション値を変更すると、オブジェクトに対するクライアント側の未同期の変更が失われます。

パーティションベースの同期の有効化

始める前に

パーティションベースの同期を有効にするには、次のものが必要です。

App Services App 。アプリの作成方法については、「アプリの作成」を参照してください。
リンクされた Atlas データソース。データソースを追加する方法については、「データソースのリンク」を参照してください。

手順

同期構成画面に移動する

Device Sync ルールを定義し、アプリケーションで Device Sync を有効にするには、左側のナビゲーションメニューから Device Syncの構成画面に移動します。

注意

同期ルールは変更できません

Device Sync を有効にすると同時に Device Sync ルールを定義します。 Device Sync が有効になっている場合は、Device Sync を終了して新しいルールで再度有効にしない限り、アプリの Device Sync ルールを変更することはできません。

[ Development Details ] を選択します

アプリケーション内の単一のリンクされたクラスターに対して Device Sync を有効にできます。使用するクラスターを決定し、 Select a Cluster To Syncドロップダウンメニューから選択します。

パーティションキーの選択

Device Sync パーティションキーは、同期されたすべてのドキュメントのフィールドで、各ドキュメントをクライアント側の Realm にマッピングします。 Device Sync ルールはパーティションレベルで適用されるため、データモデルとアクセスパターンを考慮することが特に重要です。パーティションキーとその選択方法の詳細については、「パーティション」を参照してください。

注意

パーティションキーは必須または任意にすることができます。パーティションキーフィールドが任意の場合、パーティションキーを除外しているか、パーティションキーの null 値を持つ MongoDB ドキュメントはすべて null パーティションに送信されます。パーティションキーフィールドが必須の場合、Device Sync はパーティションキーの有効な値がない MongoDB ドキュメントを無視します。 MongoDB コレクションから無効または欠落しているパーティション値を持つ Device Sync が必要な場合を除き、必須パーティションキーを使用することをお勧めします。

読み取りおよび書込み権限の定義

Define Permissionsセクションでは、Atlas App Services が動的に評価して、特定のパーティション内のデータに対するユーザーの読み取りおよび書込み権限を決定するJSON 式を定義できます。

Device Sync ルール式は、Realm を開いたユーザーに解決される%%userと、Realm のパーティションキー値に解決される%%partitionにアクセスできます。より複雑なケースを処理するには、 %functionなどの演算子を使用することもできます。例については、「ロールベースの権限」を参照してください。

特定のパーティションに対するユーザーの読み取りおよび書込み権限を決定する方法が特定されたら、 ReadとWriteの入力で対応する JSON 式を定義します。

デフォルトの高度な構成動作の確認

Advanced Configurationセクションを展開します。

App Services アプリは、デフォルトで有効になっている高度な最適化機能を提供します。

クライアントがオフラインできる時間の長さを変更する場合は、 Advanced Configurationセクションで変更できます。

同期をオンにする

同期されたクラスターのルールを設定したので、残りの操作はすべて、クライアントアプリケーションに対して Device Sync を有効にするだけです。 Enable Syncをクリックし、表示される推奨事項をメモし、選択を確認します。

MongoDB Atlas ユーザーの認証

MongoDB Atlas Admin API キーを使用して CLI にログインします。

appservices login --api-key="<my api key>" --private-api-key="<my private api key>"

アプリの最新バージョンを取得する

アプリの構成ファイルのローカルコピーを取得します。アプリの最新バージョンを取得するには、次のコマンドを実行します。

appservices pull --remote="<Your App ID>"

また、UI または管理 API からアプリケーションの構成ファイルのコピーをエクスポートすることもできます。方法については、「アプリをエクスポートする」を参照してください。

同期構成を追加する

アプリケーション内の単一のリンクされたクラスターの同期を有効にできます。

App Services Appには、同期構成ファイルがある sync ディレクトリがあります。同期をまだ有効にしていない場合、このディレクトリは空になります。

次のようなconfig.jsonを追加します。

{
  "type": "partition",
  "state": <"enabled" | "disabled">,
  "development_mode_enabled": <Boolean>,
  "service_name": "<Data Source Name>",
  "database_name": "<Database Name>",
  "partition": {
    "key": "<Partition Key Field Name>",
    "type": "<Partition Key Type>",
    "permissions": {
      "read": { <Expression> },
      "write": { <Expression> }
    }
  },
  "client_max_offline_days": <Number>,
  "is_recovery_mode_disabled": <Boolean>
}

パーティションキーの選択

同期パーティションキーは、同期されたすべてのドキュメントのフィールドで、各ドキュメントをクライアント側の Realm にマッピングします。同期ルールはパーティションレベルで適用されるため、データモデルとアクセスパターンを考慮することが特に重要です。パーティションキーとその選択方法の詳細については、「パーティション」を参照してください。

注意

パーティションキーは必須または任意にすることができます。パーティションキーフィールドが任意の場合、パーティションキーを除外しているか、パーティションキーの null 値を持つ MongoDB ドキュメントはすべて null パーティションに送信されます。パーティションキーフィールドが必須の場合、Device Sync はパーティションキーの有効な値がない MongoDB ドキュメントを無視します。 MongoDB コレクションから無効または欠落しているパーティション値を持つ既存のデータを同期する場合を除き、必須パーティションキーを使用することをお勧めします。

使用するフィールドを決定したら、次のように、 keyフィールドにパーティションキーフィールド名を指定し、 typeフィールドにパーティションキータイプを使用してsync.partitionを更新します。

{
  ...
  "partition": {
    "key": "owner_id",
    "type": "string",
    "permissions": {
      "read": {},
      "write": {}
    }
  }
  ...
}

読み取りおよび書込み権限の定義

App Services では、ユーザーが Realm を開いて、パーティション内のデータに対する読み取りまたは書込み (write) 権限があるかどうかを判断するたびに、動的に評価するJSON 式を定義できます。

同期ルール式は、Realm を開いたユーザーに解決される%%userと、Realm のパーティションキー値に解決される%%partitionにアクセスします。より複雑なケースを処理するには、 %functionなどの演算子を使用することもできます。例については、「同期権限」を参照してください。

特定のパーティションに対するユーザーの読み取りおよび書込み権限を決定する方法が特定されたら、次のように、のフィールドとフィールドに対応する JSON 式を定義します。readwritepartition.permissions

{
  ...
  "partition": {
    "key": "owner_id",
    "type": "string",
    "permissions": {
      "read": {
        "$or": [
          { "%%user.id": "%%partition" },
          { "%%user.custom_data.shared": "%%partition" }
        ]
      },
      "write": {
        "%%user.id": "%%partition"
      }
    }
  }
  ...
}

同期最適化の値を指定する

Sync は、Sync のパフォーマンスを最適化し、クライアントのデータ回復プロセスを改善する機能を提供します。これらの機能は追加設定によって表されます。

client_max_offline_days
is_recovery_mode_disabled

client_max_offline_daysには数値を設定できます。 App Services UI 経由で同期を有効にする場合、デフォルト値は30で、これは30日を表します。

詳細については、「クライアントの最大オフライン時間」を参照してください。

リカバリモードを使用すると、クライアントのリセットが発生したときに Sync がまだ同期されていないデータの回復を試行できるようになります。 App Services UI 経由で同期を有効にすると、リカバリモードはデフォルトで有効になります。自動クライアントリセット処理のためにリカバリモードを有効にすることをお勧めします。リカバリモードを無効にしていて再度有効にする場合は、 is_recovery_mode_disabledをfalseに設定します。

詳細については、「同期されていない変更の回復」を参照してください。

{
  "type": "partition",
  "state": "enabled",
  "development_mode_enabled": true,
  "service_name": "mongodb-atlas",
  "database_name": "my-test-database",
  "partition": {
    ...
  },
  "client_max_offline_days": 30,
  "is_recovery_mode_disabled": false
}

同期構成の配置

読み取り権限および書込み権限を含む同期構成を定義したので、変更を配置してデータの同期を開始し、同期ルールを強制できます。

変更を配置するには、次のようにアプリ構成を App Services App にインポートします。

appservices push --remote="<Your App ID>"

同期するクラスターの選択

アプリケーション内の単一のリンクされたクラスターの同期を有効にできます。

同期を設定するには、クラスターのサービス構成ファイルが必要です。 Admin API を通じてすべてのサービスを一覧表示すると、構成ファイルを見つけることができます。

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services \
  -X GET \
  -h 'Authorization: Bearer <Valid Access Token>'

同期を有効にするために更新する必要があるサービスを特定します。アプリを構成するときにデフォルト名を受け入れた場合、これはnameがmongodb-atlasで、 typeがmongodb-atlasであるサービスになります。このサービスの_idが必要です。

これで、このサービスの構成ファイルを取得できます。

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services/{MongoDB_Service_ID}/config \
  -X GET \
  -h 'Authorization: Bearer <Valid Access Token>'

構成が完了したら、次のテンプレート構成を持つsyncオブジェクトを追加します。

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": <Boolean>,
    "database_name": "<Database Name>",
    "partition": {
      "key": "<Partition Key Field Name>",
      "type": "<Partition Key Type>",
      "permissions": {
        "read": { <Expression> },
        "write": { <Expression> }
      }
    },
    "client_max_offline_days": <Number>,
    "is_recovery_mode_disabled": <Boolean>
  }
  ...
}

パーティションキーの選択

Admin API を通じて、有効なすべてのパーティションキーとそれに対応するタイプのリストを取得できます。

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/sync/data?service_id=<MongoDB Service ID> \
  -X GET \
  -h 'Authorization: Bearer <Valid Access Token>'

注意

パーティションキーは必須または任意にすることができます。パーティションキーフィールドが任意の場合、パーティションキーを除外しているか、パーティションキーの null 値を持つ MongoDB ドキュメントはすべて null パーティションに送信されます。パーティションキーフィールドが必須の場合、Device Sync はパーティションキーの有効な値がない MongoDB ドキュメントを無視します。 MongoDB コレクションから無効または欠落しているパーティション値を持つ既存のデータを同期する場合を除き、必須パーティションキーを使用することをお勧めします。

使用するフィールドを決定したら、 keyフィールドにパーティションキーフィールド名を表示し、 typeフィールドにパーティションキータイプを使用してsync.partitionを更新します。

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": <Boolean>,
    "database_name": "<Database Name>",
    "partition": {
      "key": "owner_id",
      "type": "string",
      "permissions": {
        "read": { <Expression> },
        "write": { <Expression> }
      }
    },
    "client_max_offline_days": <Number>,
    "is_recovery_mode_disabled": <Boolean>
  }
  ...
}

読み取りおよび書込み権限の定義

特定のパーティションに対するユーザーの読み取りおよび書込み権限を決定する方法が特定されたら、のフィールドとフィールドに対応する JSON 式を定義します。readwritesync.partition.permissions

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": <Boolean>,
    "database_name": "<Database Name>",
    "partition": {
      "key": "owner_id",
      "type": "string",
      "permissions": {
        "read": {
          "$or": [
            { "%%user.id": "%%partition" },
            { "%%user.custom_data.shared": "%%partition" }
          ]
        },
        "write": {
          "%%user.id": "%%partition"
        }
      }
    },
    "client_max_offline_days": <Number>,
    "is_recovery_mode_disabled": <Boolean>
  }
  ...
}

同期最適化の値を指定する

Sync は、Sync のパフォーマンスを最適化し、クライアントデータ回復プロセスを改善する機能を提供します。これらの機能は追加設定によって表されます。

client_max_offline_days
is_recovery_mode_disabled

client_max_offline_daysには数値を設定できます。 App Services UI 経由で同期を有効にする場合、デフォルト値は30で、これは30日を表します。

詳細については、「クライアントの最大オフライン時間」を参照してください。

リカバリモードを使用すると、クライアントがリセットされたときに Sync が同期されていないデータの復元を試行できるようになります。 App Services UI 経由で同期を有効にすると、リカバリモードはデフォルトで有効になります。自動クライアントリセット処理のためにリカバリモードを有効にすることをお勧めします。リカバリモードを有効にするには、 is_recovery_mode_disabledをfalseに設定します。

詳細については、「同期されていない変更の回復」を参照してください。

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": true,
    "database_name": "my-test-database",
    "partition": {
      ...
    },
    "client_max_offline_days": 30,
    "is_recovery_mode_disabled": false
  }
  ...
}

同期構成の配置

読み取り権限および書込み権限を含む同期構成を定義したので、変更を配置してデータの同期を開始し、同期ルールを強制できます。

変更を配置するには、同期構成でクラスター構成を更新する管理 API リクエストを送信します。

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services/{MongoDB_Service_ID}/config \
  -X PATCH \
  -h 'Authorization: Bearer <Valid Access Token>' \
  -d @/sync/config.json

パーティションベースのルールと権限

ユーザーがクライアントアプリから同期された Realm を開くたびに、App Services はアプリのルールを評価し、ユーザーがパーティションに対する読み取りおよび書込み権限を持っているかどうかを判断します。ユーザーには、Realm 内のデータを同期および読み取りを行うための読み取り権限があり、オブジェクトを作成、変更、または削除するには書込み権限が必要です。書込み権限は読み取り権限を意味するため、ユーザーが書込み権限を持っている場合は読み取り権限も付与されます。

パーティションベースの同期ルールの動作

同期ルールは特定のパーティションに適用され、パーティションキーによってアプリのデータモデルに結合されます。スキーマを設計する際には、次の動作を考慮して、適切なデータアクセスの粒度を確保し、機密情報が誤って流出しないようにしてください。

同期ルールは、ユーザーに基づいて動的に適用されます。あるユーザーはパーティションへの完全な読み取りおよび書込みアクセス権を持つことができ、別のユーザーは読み取り権限のみを持つか、パーティションに完全にアクセスできない場合があります。 JSON 式を定義することで、これらのアクセス許可を制御します。
同期ルールは、パーティション内のすべてのオブジェクトに等しく適用されます。ユーザーが特定のパーティションに対して読み取りまたは書込み (write) 権限を持つ場合は、パーティション内の任意のオブジェクトのすべての同期されたフィールドを読み取りまたは変更できます。
書込み権限には読み取り権限が必要なため、パーティションへの書込みアクセス権を持つユーザーは、定義された読み取り権限ルールに関係なく、読み取りアクセス権も付与されます。

パーティションベースの同期権限

App Services は、各パーティション内のデータを保護するために、動的なユーザー固有の読み取りおよび書込み権限を強制します。 JSON ルール式を使用して、特定のユーザーが指定されたパーティション内のデータへの読み取りアクセス権または書込みアクセス権を制御する権限を定義します。 App Services は、同期された Realm を開くたびにユーザーの権限を評価します。

Tip

ルール式は、 %%partitionや%%userなどの JSON 展開を使用して、リクエストのコンテキストに基づいてユーザーの権限を動的に決定できます。

重要な概念

読み取り権限

特定のパーティションに対する読み取り権限を持つユーザーは、対応する同期された Realm 内の任意のオブジェクトのすべてのフィールドを表示できます。読み取り権限では、ユーザーによるデータの変更は許可されません。

書込み権限

特定のパーティションに対する書込み (write) 権限を持つユーザーは、対応する同期された Realm 内の任意のオブジェクトの任意のフィールドの値を変更できます。書込み権限には読み取り権限が必要であるため、データを変更できるすべてのユーザーは、変更の前後でそのデータを表示できます。

権限戦略

重要

関係はパーティションにまたがることはできません

Flexible Syncを使用するアプリでは、オブジェクトは同じパーティション内の他のオブジェクトとの関係のみを持つことができます。オブジェクトは、パーティションキーの値が一致する限り、異なるデータベースとコレクション（同じクラスター内）に存在できます。

読み取り権限式と書込み権限式は、パーティション戦略に適用される権限戦略のセットとして構成できます。次の戦略では、アプリの同期読み取りおよび書込み権限を定義するために使用できる一般的なアプローチの概要を説明します。

グローバル権限

すべてのパーティションのすべてのユーザーに適用するグローバル権限を定義できます。これは実質的に、すべてのユーザーに適用される汎用の読み取りまたは書込み権限を優先するために、ユーザー固有の権限を実装しない選択です。

グローバルな読み取りまたは書込み権限を定義するには、ブール値、または常に同じブール値に評価されるJSON 式を指定します。

例

説明

true

式trueは、すべてのユーザーがすべてのパーティションに対して指定されたアクセス権限を持つことを意味します。

false

式falseは、すべてのパーティションに対して指定されたアクセス権限を持つユーザーはいないことを意味します。

{ "%%true": true }

この式は常にtrueと評価されるため、実質的にtrueを直接指定するのと同じになります。

特定のパーティションに対する権限

パーティション値を明示的に指定することで、特定のパーティションまたはパーティションのグループに適用する権限を定義できます。

例

説明

{ "%%partition": "PUBLIC" }

この式は、パーティション値が"Public"のデータに対して特定のアクセス権限があることを意味します。

{
  "%%partition": {
    "$in": [
      "PUBLIC (NA)",
      "PUBLIC (EMEA)",
      "PUBLIC (APAC)"
    ]
  }
}

この式は、指定されたパーティション値のいずれかを持つデータに対して、すべてのユーザーが特定のアクセス権限を持つことを意味します。

特定のユーザーの権限

ID 値を明示的に指定することで、特定のユーザーまたはユーザーのグループに適用する権限を定義できます。

例

説明

{ "%%user.id": "5f4863e4d49bd2191ff1e623" }

この式は、ID "5f4863e4d49bd2191ff1e623"を持つユーザーが、任意のパーティション内のデータに対して指定されたアクセス権限を持っていることを意味します。

{
  "%%user.id": {
    "$in": [
      "5f4863e4d49bd2191ff1e623",
      "5f48640dd49bd2191ff1e624",
      "5f486417d49bd2191ff1e625"
    ]
  }
}

この式は、指定されたユーザー ID 値の 1 つを持つすべてのユーザーが、任意のパーティション内のデータに対して指定されたアクセス権限を持つことを意味します。

ユーザーデータに基づく権限

カスタムユーザーデータドキュメントで定義された特定のデータ、メタデータフィールド、または認証プロバイダからのその他のデータに基づいて、ユーザーに適用する権限を定義できます。

例

説明

{ "%%user.custom_data.readPartitions" : "%%partition" }

この式は、パーティション値がカスタムユーザーデータのreadPartitionsフィールドにリストされている場合、ユーザーはパーティションへの読み取りアクセス権を持つことを意味します。

{ "%%user.data.writePartitions" : "%%partition" }

この式は、パーティション値がユーザーオブジェクトのdata.writePartitionsフィールドにリストされている場合、ユーザーはパーティションへの書込み (write) アクセス権を持つことを意味します。

関数ルール

ブール値を返す関数を評価することで、複雑な動的権限を定義できます。これは、外部システムやExpress JSON式のみでできないその他のカスタムロジックにアクセスする必要がある権限スキームに役立ちます。

例

説明

{
  "%%true": {
    "%function": {
      "name": "canReadPartition",
      "arguments": ["%%partition"]
    }
  }
}

// canReadPartition
exports = async (partition) => {
  const cluster = context.services.get("mongodb-atlas");
  const permissions = cluster
    .db("myApp")
    .collection("permissions");
  const { canRead } = await permissions.findOne({ partition });
  return canRead.includes(context.user.id);
}

この式はcanReadPartition関数を呼び出し、その最初で唯一の引数としてパーティション値を渡します。この関数は、MongoDB コレクションからパーティションに対するユーザーの権限を検索し、ユーザーが要求されたパーティション内のデータを読み取ることができるかどうかを示すブール値を返します。

パーティションベースの同期ルールを App Services ルールに移行

パーティションベースの同期アプリを Flexible Sync に移行する場合は、データアクセスルールも移行する必要があります。

一部のパーティションベースの同期ルール戦略は、App Services ルールに直接変換できません。次のような権限を手動で移行する必要がある場合があります。

%function 演算子。
関数ルールは Flexible Sync と互換性がないため、移行できません。
%%partition 展開。
App Services ルールでは、 %%partitionと同等の展開がないため、移行できません。
%or、 %not 、 %nor 、 %andの展開。
これらの権限は機能する可能性がありますが、期待される動作を確認するためにテストする必要がある十分なニュアンスがあります。新しい権限のテストは、移行中のアプリでは機能しません。手動で移行された権限をテストするには、新しいアプリが必要です。

サポートされているすべての展開については、 Flexible Sync 互換展開のリストを参照してください。

また、権限の操作方法の詳細については、「 Device Sync 権限ガイド」を参照してください。

パーティション戦略

パーティション戦略は、オブジェクトをパーティションに分割するためのキーと値のパターンです。異なるユースケースは異なるパーティション戦略を呼び出します。同じアプリ内でパーティション戦略を組み合わせて、より大きな戦略を構築できます。これにより、任意の複雑なユースケースを処理できます。

どちらの戦略を使用するかは、アプリのデータモデルとアクセスパターンによって異なります。公開データとプライベートデータの両方を持つアプリを検討してください。お知らせなどのデータを、パブリックパーティションに配置する場合があります。個人情報などの他のデータを特権ユーザーに制限できます。

パーティション戦略を開発する際には、次のことを検討します。

データセキュリティ:ユーザーは、データのサブセットに対して異なる読み取りアクセス権限と書込みアクセス権限を必要とする場合があります。ドキュメントのタイプにユーザーが必要とする権限を検討してください。ユーザーはパーティション内のすべてのドキュメントに対して同じ権限を持ちます。
ストレージ容量:一部のデバイスとプラットフォームでは、クライアントアプリのデバイス上ストレージが制限されている場合があります。パーティション戦略では、ストレージの制限を考慮する必要があります。ユーザーが同期されたデータをデバイスに保存できることを確認します。

Tip

戦略を組み合わせる

クエリstringを値として持つ _partition のようなパーティションキー名を使用できます。これにより、同じアプリで複数の戦略を使用できます。例:

_partitionKey: "user_id=abcdefg"
_partitionKey: "team_id=1234&city='New York, NY'"

関数とルール式を使用してstringを解析できます。同期は、組み合わせられた戦略に基づいて、ユーザーがパーティションにアクセスできるかどうかを判断できます。

Firehose 戦略

Firehose パーティション戦略では、すべてのドキュメントが単一のパーティションにグループ化されます。この構造では、すべてのユーザーがすべてのアプリのデータを自分のデバイスに同期します。このアプローチは、機能的にはデータを分割しないという決定です。これは、基本的なアプリケーションまたは小規模な公開データセットで機能します。

データセキュリティ。 すべてのデータは、パーティションを使用する Realm を持つクライアントに公開されます。ユーザーがパーティションに対して読み取りまたは書込みアクセス権を持つ場合、任意のドキュメントの読み取りや書込みができます。
ストレージ容量。 すべてのユーザーは、パーティション内のすべてのドキュメントを同期します。すべてのデータは、最も制限されたストレージ制限内に収まる必要があります。この戦略は、データセットが小さく、すぐに大きくならない場合にのみ使用してください。

Firehose を作成する方法の 1 つは、パーティションキーを任意フィールドとして設定することです。このフィールドの値をどのドキュメントにも含めないでください。 App Services は、パーティション値を含まないドキュメントをnull パーティションにマッピングします。

静的パーティション値を設定することもできます。これは、パーティション値がユーザーまたはデータに基づいて変更されない場合だけです。たとえば、すべてのクライアントにわたる Realm では、パーティション値"MyPartitionValue"が使用できます。

例

アプリを使用すると、ユーザーはローカルの上位チームのスコアと統計情報を閲覧できます。コレクションとgames teamsコレクションに含まれる次のドキュメントを検討してみましょう。

collection games: [
  { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
  { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
]
collection teams: [
  { name: "Brook Ridge Miners" }
  { name: "Southside Rockets" }
  { name: "Uptown Bombers" }
]

合計プレイ数は少ないです。少数のローカルチームは、年に数回のゲームしかプレイしません。ほとんどのデバイスは、すべてのゲームデータをダウンロードして、オフラインで簡単にアクセスできるはずです。この場合は、ファイアウォール戦略が適切です。データはパブリックであり、ドキュメントにはパーティションキーは必要ありません。

この戦略はコレクションを次の Realm にマッピングします。

realm null: [
  Game { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  Game { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  Game { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  Game { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
  Game { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  Game { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
  Team { name: "Brook Ridge Miners" }
  Team { name: "Southside Rockets" }
  Team { name: "Uptown Bombers" }
]

ユーザー戦略

ユーザーパーティション戦略では、各ユーザーのプライベートドキュメントをグループ化します。これらのドキュメントは、そのユーザーに固有のパーティションにGoされます。これは、各ドキュメントに所有者がいて、他のドキュメントを必要とするユーザーがいない場合に機能します。所有者を識別するユーザー名または ID によって、自然なパーティションキーが作成されます。

データセキュリティ。 ユーザーパーティション内のデータは特定のユーザーに固有です。そのユーザーのプライベート情報が含まれる場合があります。各ユーザーは自分のパーティションのみを同期します。他のユーザーは、パーティション内のドキュメントにアクセスできません。
ストレージ容量。 各ユーザーは、自分のパーティションからのデータのみを同期します。データはデバイスのストレージ制約内に収まる必要があります。この戦略は、各ユーザーが管理可能なデータ量がある場合にのみ使用してください。

例

言語ストリーミングアプリは、各ユーザーのプレイリストとアプリの評価に関するデータを保存します。コレクションとplaylists ratingsコレクションに含まれる次のドキュメントを検討してみましょう。

collection playlists: [
  { name: "Work", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  { name: "Party", owner_id: "cat_enthusiast_92", song_ids: [ ... ] }
  { name: "Soup Tunes", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  { name: "Disco Anthems", owner_id: "PUBLIC", song_ids: [ ... ] }
  { name: "Deep Focus", owner_id: "PUBLIC", song_ids: [ ... ] }
]
collection ratings: [
  { owner_id: "dog_enthusiast_95", song_id: 3, rating: -1 }
  { owner_id: "cat_enthusiast_92", song_id: 1, rating: 1 }
  { owner_id: "dog_enthusiast_95", song_id: 1, rating: 1 }
]

すべてのドキュメントにはowner_idフィールドが含まれます。これは、ユーザーパーティション戦略に適したパーティションキーです。ドキュメントを個々のユーザーに自然にマッピングします。これにより、各デバイス上のデータは、デバイスのユーザーのプレイリストと評価に制限されます。

ユーザーは、ユーザー Realm への読み取りアクセス権および書込みアクセス権があります。これには、作成したプレイリストと、読み込みに与えた評価が含まれています。
すべてのユーザーは、パーティション値PUBLICの Realm への読み取りアクセス権を持ちます。これには、すべてのユーザーが利用できるプレイリストが含まれています。

この戦略はコレクションを次の Realm にマッピングします。

realm dog_enthusiast_95: [
  Playlist { name: "Work", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  Playlist { name: "Soup Tunes", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  Rating { owner_id: "dog_enthusiast_95", song_id: 3, rating: -1 }
  Rating { owner_id: "dog_enthusiast_95", song_id: 1, rating: 1 }
]
realm cat_enthusiast_92: [
  Playlist { name: "Party", owner_id: "cat_enthusiast_92", song_ids: [ ... ] }
  Rating { owner_id: "cat_enthusiast_92", song_id: 1, rating: 1 }
]
realm PUBLIC: [
  Playlist { name: "Disco Anthems", owner_id: "PUBLIC", song_ids: [ ... ] }
  Playlist { name: "Deep Focus", owner_id: "PUBLIC", song_ids: [ ... ] }
]

チーム戦略

チームパーティション戦略では、ユーザーのチームが共有するプライベートドキュメントをグループ化します。チームには、店舗の従業員またはバンドのメンバーが含まれる場合があります。各チームには、そのグループに固有のパーティションがあります。チーム内の全ユーザーは、チームのドキュメントへのアクセスと所有権を共有します。

データセキュリティ。 チームパーティション内のデータは、特定のチームに固有です。チームにはプライベートであり、チームのメンバーには非公開のデータが含まれる場合があります。各ユーザーは、所属するチームのパーティションを同期します。チームに所属していないユーザーは、チームのパーティション内のドキュメントにアクセスできません。
ストレージ容量:各ユーザーは自分のチームのデータのみを同期します。ユーザーチームのデータは、デバイスのストレージ制約に収まる必要があります。ユーザーが管理可能な数のチームに属している場合は、この戦略を使用します。ユーザーが多くのチームに属している場合、結合された Realm には多くのデータが含まれる可能性があります。一度に同期されるチームパーティションの数を制限する必要がある場合があります。

例

アプリを使用すると、ユーザーは他のユーザーと連携するためのプロジェクトを作成できます。コレクションとprojects tasksコレクションに含まれる次のドキュメントを検討してみましょう。

collection projects: [
  { name: "CLI", owner_id: "cli-team", task_ids: [ ... ] }
  { name: "API", owner_id: "api-team", task_ids: [ ... ] }
]
collection tasks: [
  { status: "complete", owner_id: "api-team", text: "Import dependencies" }
  { status: "inProgress", owner_id: "api-team", text: "Create app MVP" }
  { status: "inProgress", owner_id: "api-team", text: "Investigate off-by-one issue" }
  { status: "todo", owner_id: "api-team", text: "Write tests" }
  { status: "inProgress", owner_id: "cli-team", text: "Create command specifications" }
  { status: "todo", owner_id: "cli-team", text: "Choose a CLI framework" }
]

すべてのドキュメントにはowner_idフィールドが含まれます。これは、チームパーティション戦略に適したパーティションキーです。ドキュメントを個々のチームに自然にマッピングします。これにより、各デバイスのデータが制限されます。ユーザーには、自分に関連するプロジェクトとタスクのみが含まれます。

ユーザーは、メンバーであるチームによって所有されるパーティションへの読み取りおよび書込みアクセス権があります。

teamsまたはusersコレクションに保存されているデータは、ユーザーをチームメンバーシップにマッピングできます。

collection teams: [
  { name: "cli-team", member_ids: [ ... ] }
  { name: "api-team", member_ids: [ ... ] }
]
collection users: [
  { name: "Joe", team_ids: [ ... ] }
  { name: "Liz", team_ids: [ ... ] }
  { name: "Matt", team_ids: [ ... ] }
  { name: "Emmy", team_ids: [ ... ] }
  { name: "Scott", team_ids: [ ... ] }
]

この戦略はコレクションを次の Realm にマッピングします。

realm cli-team: [
  Project { name: "CLI", owner_id: "cli-team", task_ids: [ ... ] }
  Task { status: "inProgress", owner_id: "cli-team", text: "Create command specifications" }
  Task { status: "todo", owner_id: "cli-team", text: "Choose a CLI framework" }
]
realm api-team: [
  Project { name: "API", owner_id: "api-team", task_ids: [ ... ] }
  Task { status: "complete", owner_id: "api-team", text: "Import dependencies" }
  Task { status: "inProgress", owner_id: "api-team", text: "Create app MVP" }
  Task { status: "inProgress", owner_id: "api-team", text: "Investigate off-by-one issue" }
  Task { status: "todo", owner_id: "api-team", text: "Write tests" }
]

チャネル戦略

チャンネルパーティション戦略は、共通のトピックまたはドメインのドキュメントをグループ化します。各トピックまたはドメインには独自のパーティションがあります。ユーザーは、特定のチャンネルにアクセスするかサブスクライブするかを選択できます。名前または ID によって、公開リストでこれらのチャンネルが識別される場合があります。

データセキュリティ。 チャンネルパーティション内のデータは、トピックまたは領域に固有です。ユーザーはこれらのチャネルにアクセスすることを選択できます。チャンネルのサブセットへのユーザーのアクセスを制限できます。ユーザーがチャンネルにアクセスできないようにすることもできます。ユーザーがチャンネルに対して読み取りまたは書き込み権限を持っている場合、パーティション内の任意のドキュメントにアクセスできます。
ストレージ容量。 ユーザーは、許可された任意のチャンネルからのデータを同期することを選択できます。ユーザーのチャネルからのすべてのデータは、デバイスのストレージ制約内に収まる必要があります。この戦略を使用して、パブリックまたは半プライベートのデータセットを分割します。この戦略では、ストレージの制約に収まらないデータセットは分割されます。

例

アプリを使用すると、ユーザーはトピックに基づいてチャットルームを作成できます。ユーザーは、利用可能な任意のトピックを検索してチャンネルに参加することができます。コレクションとchatrooms messagesコレクション内の次のドキュメントを検討します。

collection chatrooms: [
  { topic: "cats", description: "A place to talk about cats" }
  { topic: "sports", description: "We like sports and we don't care who knows" }
]
collection messages: [
  { topic: "cats", text: "Check out this cute pic of my cat!", timestamp: 1625772933383 }
  { topic: "cats", text: "Can anybody recommend a good cat food brand?", timestamp: 1625772953383 }
  { topic: "sports", text: "Did you catch the game last night?", timestamp: 1625772965383 }
  { topic: "sports", text: "Yeah what a comeback! Incredible!", timestamp: 1625772970383 }
  { topic: "sports", text: "I can't believe how they scored that goal.", timestamp: 1625773000383 }
]

すべてのドキュメントにはtopicフィールドが含まれます。これは、チャンネルパーティション戦略に適したパーティションキーです。ドキュメントを個々のチャンネルに自然にマッピングします。これにより、各デバイス上のデータが削減されます。データには、ユーザーが選択したチャンネルのメッセージとメタデータのみが含まれます。

ユーザーは、サブスクライブされているチャットルームへの読み取りアクセス権および書込みアクセス権があります。ユーザーは、他のユーザーが送信したメッセージであっても、任意のメッセージを変更または削除できます。書込み権限を制限するには、ユーザーに読み取り専用アクセス権を付与できます。次に、サーバーレス関数でメッセージの送信を取り扱います。

ユーザーのサブスクライブチャンネルをchatroomsまたはusersコレクションのいずれかに保存します。

collection chatrooms: [
  { topic: "cats", subscriber_ids: [ ... ] }
  { topic: "sports", subscriber_ids: [ ... ] }
]
collection users: [
  { name: "Joe", chatroom_ids: [ ... ] }
  { name: "Liz", chatroom_ids: [ ... ] }
  { name: "Matt", chatroom_ids: [ ... ] }
  { name: "Emmy", chatroom_ids: [ ... ] }
  { name: "Scott", chatroom_ids: [ ... ] }
]

この戦略はコレクションを次の Realm にマッピングします。

realm cats: [
  Chatroom { topic: "cats", description: "A place to talk about cats" }
  Message { topic: "cats", text: "Check out this cute pic of my cat!", timestamp: 1625772933383 }
  Message { topic: "cats", text: "Can anybody recommend a good cat food brand?", timestamp: 1625772953383 }
]
realm sports: [
  Chatroom { topic: "sports", description: "We like sports and we don't care who knows" }
  Message { topic: "sports", text: "Did you catch the game last night?", timestamp: 1625772965383 }
  Message { topic: "sports", text: "Yeah what a comeback! Incredible!", timestamp: 1625772970383 }
  Message { topic: "sports", text: "I can't believe how they scored that goal.", timestamp: 1625773000383 }
]

リージョン戦略

リージョンパーティション戦略は、ロケーションまたはリージョンに関連するドキュメントをグループ化します。各パーティションには、それらの領域に固有のドキュメントが含まれています。

データセキュリティ。 データは特定の地理的領域に固有です。ユーザーの現在のリージョンへのアクセスを制限できます。あるいは、リージョンごとにデータへのアクセスを許可します。
ストレージ容量。 ストレージのニーズは、リージョンのサイズと使用パターンによって異なります。ユーザーは、自分のリージョン内のデータのみを同期できます。どのリージョンのデータも、デバイスのストレージ制約内に収まる必要があります。ユーザーが複数のリージョンを同期する場合は、小さなサブリージョンに分割します。これにより、不要なデータの同期を回避できます。

例

アプリを使用すると、ユーザーは近くのレストランを検索して、そのメニューから注文できます。 restaurantsコレクションに含まれる以下の文書を考えます。

collection restaurants: [
  { city: "New York, NY", name: "Joe's Pizza", menu: [ ... ] }
  { city: "New York, NY", name: "Han Dynasty", menu: [ ... ] }
  { city: "New York, NY", name: "Harlem Taste", menu: [ ... ] }
  { city: "Chicago, IL", name: "Lou Malnati's", menu: [ ... ] }
  { city: "Chicago, IL", name: "Al's Beef", menu: [ ... ] }
  { city: "Chicago, IL", name: "Nando's", menu: [ ... ] }
]

すべてのドキュメントにはcityフィールドが含まれます。これは、リージョンパーティション戦略に適したパーティションキーです。ドキュメントを特定の物理領域に自然にマッピングします。これにより、データはユーザーの現在の都市のメッセージとメタデータに制限されます。ユーザーは、現在のリージョンのレストランへの読み取りアクセス権を持ちます。アプリケーションロジックでユーザーのリージョンを決定できます。

この戦略はコレクションを次の Realm にマッピングします。

realm New York, NY: [
 { city: "New York, NY", name: "Joe's Pizza", menu: [ ... ] }
 { city: "New York, NY", name: "Han Dynasty", menu: [ ... ] }
 { city: "New York, NY", name: "Harlem Taste", menu: [ ... ] }
]
realm Chicago, IL: [
 { city: "Chicago, IL", name: "Lou Malnati's", menu: [ ... ] }
 { city: "Chicago, IL", name: "Al's Beef", menu: [ ... ]  }
 { city: "Chicago, IL", name: "Nando's", menu: [ ... ]  }
]

バケット戦略

バケットパーティション戦略では、ドキュメントを範囲ごとにグループ化します。ドキュメントが単位にまたがる場合、パーティションにはサブ範囲が含まれます。時間ベースのバケット範囲を検討してください。 trigger は、ドキュメントがバケット範囲から削除されると、ドキュメントを新しいパーティションに移動します。

データセキュリティ。 特定のバケットのみの読み取りまたは書き込みを行うユーザーを制限します。データはバケット間で送受信される場合があります。可能なすべてのバケットにわたるドキュメントのアクセス権限を検討してください。
ストレージ容量。 ストレージのニーズは、各バケットのサイズと使用パターンによって異なります。ユーザーがどのバケットにアクセスする必要があるかを検討してください。バケットのサイズを、デバイスのストレージ制約に収まるように制限します。ユーザーが多くのバケットを同期する場合は、小さなバケットに分割します。これにより、不要なデータの同期を回避できます。

例

IoT アプリは、1 秒あたり数回のセンサー読み取りのリアルタイムビューを表示します。バケットは、読み取りが行われてからの秒数から派生します。 readingsコレクション内の次のドキュメントについて考えてみます。

collection readings: [
  { bucket: "0s<t<=60s", timestamp: 1625773000383 , data: { ... } }
  { bucket: "0s<t<=60s", timestamp: 1625772970383 , data: { ... } }
  { bucket: "0s<t<=60s", timestamp: 1625772965383 , data: { ... } }
  { bucket: "60s<t<=300s", timestamp: 1625772953383 , data: { ... } }
  { bucket: "60s<t<=300s", timestamp: 1625772933383 , data: { ... } }
]

すべてのドキュメントにはbucketフィールドが含まれます。このフィールドは、ドキュメントを特定の時間範囲にマッピングします。ユーザーのデバイスには、ビューするウィンドウのセンサー読み取り値のみが含まれます。

ユーザーはどの時間バケットでもセンサー読み取りにアクセスできます。
センサーは、読み取りをアップロードするために書込み (write) アクセス権を持つクライアントアプリを使用します。

この戦略はコレクションを次の Realm にマッピングします。

realm 0s<t<=60s: [
  Reading { bucket: "0s<t<=60s", timestamp: 1625773000383 , data: { ... } }
  Reading { bucket: "0s<t<=60s", timestamp: 1625772970383 , data: { ... } }
  Reading { bucket: "0s<t<=60s", timestamp: 1625772965383 , data: { ... } }
]
realm 60s<t<=300s: [
  Reading { bucket: "60s<t<=300s", timestamp: 1625772953383 , data: { ... } }
  Reading { bucket: "60s<t<=300s", timestamp: 1625772933383 , data: { ... } }
]

Data Ingest

Data Ingestは Flexible Sync の機能であり、Flexible Sync を使用するアプリでは有効にできません。

パーティションベースの同期構成

パーティションベースの同期を使用する場合、Atlas App Services アプリは次の同期構成を使用します。

sync/config.json

{
  "type": "partition",
  "state": <"enabled" | "disabled">,
  "development_mode_enabled": <Boolean>,
  "service_name": "<Data Source Name>",
  "database_name": "<Development Mode Database Name>",
  "partition": {
    "key": "<Partition Key Field Name>",
    "type": "<Partition Key Type>",
    "permissions": {
      "read": { <Expression> },
      "write": { <Expression> }
    }
  },
  "last_disabled": <Number>,
  "client_max_offline_days": <Number>,
  "is_recovery_mode_disabled": <Boolean>
}

フィールド	説明
`type` String	同期モード。 Flexible Syncと古いパーティションベースの同期の 2 つの同期モードがあります。パーティションベースの同期構成の有効なオプション `"partition"`
`state` String	アプリケーションの同期プロトコルの現在の状態。有効なオプション: `"enabled"` `"disabled"`
`service_name` String	同期するMongoDB データソースの名前。サーバーレスインスタンスまたはフェデレーティッドデータベースインスタンスでは同期を使用できません。
`development_mode_enabled` Boolean	`true`の場合、アプリケーションで開発モードが有効になります。有効にすると、App Services は同期されたオブジェクトを特定のデータベース（ `database_name`で指定）に自動的に保存し、そのデータベースのコレクションスキーマのオブジェクトタイプをミラーリングします。
`database_name` String	App Services が開発モードでデータを保存する同期されたクラスター内のデータベースの名前。 App Services は、同期された型ごとにスキーマを自動的に生成し、各オブジェクト型をデータベース内のコレクションにマッピングします。
`partition.key` String	アプリのパーティションキーのフィールド名。このフィールドは、同期するオブジェクトタイプのスキーマで定義する必要があります。
`partition.type` String	パーティションキーフィールドの値の型。これは、オブジェクトスキーマで定義されている型と一致する必要があります。有効なオプション: `"string"` `"objectId"` `"long"`
`partition.permissions.read` Expression	ユーザーがパーティション内のオブジェクトを読み取る権限を持つ場合に`true`と評価される式。式が`false`と評価された場合、App Services はユーザーによるオブジェクトまたはそのプロパティの読み取りを許可しません。
`partition.permissions.write` Expression	ユーザーがパーティションにオブジェクトを書込む権限を持つ場合に`true`と評価される式。式が`false`と評価された場合、App Services はユーザーによるオブジェクトまたはそのプロパティの変更を許可しません。書込み (write) 権限には読み取り権限が必要です。ユーザーは、読みられないドキュメントに書込み (write) はできません。
`last_disabled` Number	同期が最後に一時停止または無効になった日時を、UNIX エポック（1970 年 1 月 1 日 00:00:00 UTC）からの秒数で表します。
`client_max_offline_days` Number	バックエンド圧縮プロセスが古いバージョンの Realm から同期するために必要なメタデータを積極的にプルする前に、バックエンド圧縮プロセスが待機する時間を制御します。
`is_recovery_mode_disabled` Boolean	`false`の場合、アプリケーションでリカバリモードが有効になります。有効にすると、この機能をサポートする Realm SDK は、クライアントリセットの実行時に同期されていない変更を回復しようとします。リカバリモードはデフォルトで有効になっています。

パーティションベースの同期構成を変更する

パーティションベースの Device Sync 構成に変更を加えるには、Device Sync を終了し、Device Syncを再度有効にする必要があります。 Atlas Device Sync を再有効化する間に、新しいパーティションキーを指定したり、読み取り/書込み権限を変更したりできます。 Device Sync を終了して再度有効にするときにDevice Sync Device Sync構成に変更を加えると、クライアントリセットがtriggerされます。クライアントリセットの処理の詳細については、クライアントリセットのドキュメントをお読みください。

パーティションベースの同期エラー

アプリがパーティションベースの同期を使用している場合、次のエラーが発生する可能性があります。

エラー名

説明

ErrorIllectionRealmPath

このエラーは、クライアントが間違ったタイプのパーティション値を持つ Realm を開こうとしたことを示しています。たとえば、「不正な Realm パーティションにバインドしようとしました: ObjectId 型のパーティションが必要ですが、string が見つかりました」というエラーメッセージが表示される場合があります。

このエラーから回復するには、Realm を開くために使用されたパーティション値のタイプが、Device Sync 構成のパーティションキーのタイプと一致していることを確認します。

バックエンド圧縮

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

Flexible Sync を使用するアプリは、Atlas Cluster に保存されるメタデータの量を減らすために、バックエンド圧縮を実行します。バックエンド圧縮は、Flexible Sync を使用してすべてのアプリに対して自動的に実行されるメンテナンスプロセスです。バックエンドは圧縮を使用して、不要な変更セットメタデータを排除し、Realm の履歴を最適化します。プロセスは、その効果が後で新しい指示によって上書きされるすべての指示を削除します。

例

次の Realm 履歴を検討します。

元の履歴

CREATE table1.object1
UPDATE table1.object1.x = 4
UPDATE table1.object1.x = 10
UPDATE table1.object1.x = 42

次の履歴も同じ状態に集約されますが、不要な中間変更はありません。

圧縮された履歴

CREATE table1.object1
UPDATE table1.object1.x = 42

注意

Flexible Syncでは、バックエンド圧縮を使用して、Atlas に保存される Device Sync 履歴を削減します。 Flexible Sync は、とクライアントの最大オフライン時間を削除することで、これを実現します。

戻る

whatmi

プッシュ通知 [非推奨]

注意

パーティションベースの同期から Flexible Sync への移行

重要な概念

例

例

重要な用語

パーティション

パーティションキー

例

パーティションキーの変更

警告

同期終了後の同期の復元

パーティション値

警告

パーティションベースの同期の有効化

始める前に

手順

同期構成画面に移動する

注意

同期ルールは変更できません

[ Development Details ] を選択します

パーティションキーの選択

注意

読み取りおよび書込み権限の定義

デフォルトの高度な構成動作の確認

同期をオンにする

MongoDB Atlas ユーザーの認証

アプリの最新バージョンを取得する

同期構成を追加する

パーティションキーの選択

注意

読み取りおよび書込み権限の定義

同期最適化の値を指定する

同期構成の配置

同期するクラスターの選択

パーティションキーの選択

注意

読み取りおよび書込み権限の定義

同期最適化の値を指定する

同期構成の配置

パーティションベースのルールと権限

パーティションベースの同期ルールの動作

パーティションベースの同期権限

Tip

重要な概念

読み取り権限

書込み権限

権限戦略

重要

関係はパーティションにまたがることはできません

グローバル権限

特定のパーティションに対する権限

特定のユーザーの権限

ユーザー データに基づく権限

関数ルール

パーティションベースの同期ルールを App Services ルールに移行

パーティション戦略

Tip

戦略を組み合わせる

Firehose 戦略

例

ユーザー戦略

例

チーム戦略

例

チャネル戦略

例

リージョン戦略

例

バケット戦略

例

Data Ingest

パーティションベースの同期構成

パーティションベースの同期構成を変更する

パーティションベースの同期エラー

バックエンド圧縮

例

注意

ユーザーデータに基づく権限