Docs Menu
Docs Home
/ /
Atlas App Services
/

파티션 기반 동기화

이 페이지의 내용

  • 주요 개념
  • 주요 용어
  • 파티션
  • 파티션 키
  • 파티션 키 변경
  • 파티션 값
  • 파티션 기반 동기화 활성화
  • 시작하기 전에
  • 절차
  • 파티션 기반 규칙 및 권한
  • 파티션 기반 동기화 규칙 동작
  • 파티션 기반 동기화 권한
  • 주요 개념
  • 읽기 권한
  • 쓰기 권한
  • 권한 전략
  • 글로벌 권한
  • 특정 파티션에 대한 권한
  • 특정 사용자에 대한 권한
  • 사용자 데이터 기반 권한
  • 함수 규칙
  • 파티션 기반 동기화 규칙을 App Services 규칙으로 마이그레이션
  • 파티션 전략
  • 파이어호스 전략
  • 사용자 전략
  • 팀 전략
  • 채널 전략
  • 리전 전략
  • 버킷 전략
  • 데이터 인제스트
  • 파티션 기반 동기화 구성
  • 파티션 기반 동기화 구성 변경하기
  • 파티션 기반 동기화 오류
  • 백엔드 압축

Atlas Device Sync에는 Flexible Sync와 이전 파티션 기반 동기화, 두 가지 동기화 모드가 있습니다. 파티션 기반 동기화는 더 이상 사용되지 않으며 새 동기화 구성에서는 허용되지 않습니다.

이 페이지의 정보는 아직 파티션 기반 동기화를 사용하고 있는 사용자를 위한 것입니다.

참고

파티션 기반 동기화에서 Flexible Sync로 마이그레이션

파티션 기반 동기화 앱을 Flexible Sync로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 자세한 내용은 Device Sync 모드 마이그레이션마이그레이션 참조하세요.

파티션 기반 동기화에서 동기화된 클러스터의 문서는 '파티션 키'로 지정된 필드에 대해 동일한 값을 가짐으로써 '파티션'을 형성합니다. 파티션의 모든 문서는 지정된 사용자에 대해 동일한 읽기/쓰기 권한을 갖습니다.

사용자가 문서 를 읽거나 쓰기 (write) 수 있는지 여부를 결정하는 값을 갖는 파티션 키 를 정의합니다. App Services 는 규칙 설정하다 를 평가하여 사용자가 지정된 파티션을 읽거나 쓰기 (write) 수 있는지 여부를 결정합니다. App Services 는 파티션을 개별 동기화된 .realm 파일에 직접 매핑합니다. 동기화 영역 의 각 객체 에는 파티션에 해당 문서 가 있습니다.

예시

파티션 기반 동기화를 사용하는 인벤토리 관리 애플리케이션을 예로 들어 보겠습니다. store_number 파티션 키로 사용하면 각 스토어는 해당 인벤토리와 관련된 문서를 읽고 쓸 수 있습니다.

이 유형의 앱에 대한 사용 권한의 예는 다음과 같습니다.

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

매장 직원은 매장 번호가 Store 42인 문서에 대한 읽기 및 쓰기 권한을 가질 수 있습니다.

한편 고객은 스토어 인벤토리에 대한 읽기 전용 액세스 권한을 가질 수 있습니다.

클라이언트에서는 동기화된 영역을 열 때 파티션 키의 값을 전달합니다. 그런 다음 App Services는 파티션 키 값이 클라이언트 애플리케이션에서 전달한 값과 일치하는 객체를 동기화합니다.

예시

위의 스토어 인벤토리 예를 기반으로 하면 SDK가 동기화 구성에서 store42 partitionValue로 전달될 수 있습니다. 이는 partitionValuestore42인 모든 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 Atlas 클러스터가 특정 버전의 MongoDB를 실행해야 합니다. 파티션 기반 동기화에는 MongoDB 4.4.0 이상이 필요합니다.

파티션은 동일한 파티션 키 값을 공유하는 객체의 컬렉션입니다.

MongoDB Atlas 클러스터는 여러 개의 원격 서버로 구성됩니다. 이러한 서버는 동기화된 데이터를 위한 스토리지를 제공합니다. Atlas 클러스터는 문서를 collection에 저장합니다. 각 MongoDB collection은 서로 다른 Realm 객체 유형에 매핑됩니다. collection의 각 문서는 특정 Realm 객체를 나타냅니다.

동기화 영역은 장치의 로컬 파일입니다. 동기화 영역에는 최종 사용자와 관련된 일부 또는 모든 객체가 포함될 수 있습니다. 클라이언트 앱은 둘 이상의 동기화 영역을 사용하여 애플리케이션에 필요한 모든 객체에 액세스할 수 있습니다.

파티션은 Realm Database의 객체를 MongoDB의 문서에 연결합니다. 동기화 영역 파일을 초기화할 때 해당 매개변수 중 하나는 파티션 값입니다. 클라이언트 앱은 동기화 영역에서 객체를 생성합니다. 해당 객체가 동기화되면 파티션 값은 MongoDB 문서의 필드가 됩니다. 이 필드의 값에 따라 클라이언트가 액세스할 수 있는 MongoDB 문서가 결정됩니다.

상위 수준에서:

  • 파티션은 동기화된 클러스터에 있는 문서의 하위 세트에 매핑됩니다.

  • 파티션의 모든 문서는 특정 사용자에 대해 동일한 읽기/쓰기 권한을 갖습니다.

  • Atlas App Services가 각 파티션을 동기화된 개별 .realm 파일에 매핑합니다.

  • 동기화 영역의 각 객체에는 파티션에 해당 문서가 있습니다.

모양과 색상 그룹을 사용하여 분할을 설명하는 다이어그램입니다. MongoDB 컬렉션은 (객체 유형과 동일한) 모양별로 그룹화하고 영역은 색상별로 그룹화합니다(파티션 값과 동일).

파티션은 Atlas 클러스터에서 데이터의 형태를 형성합니다. 각 도형은 객체 유형을 나타냅니다. 파티션은 각 도형의 color(빨간색, 녹색, 파란색)에 따라 결정됩니다.

파티션 키Atlas Device Sync를 구성할 때 지정하는 명명된 필드입니다. Device Sync에서는 이 키를 사용하여 지정된 문서가 들어 있는 파티션을 확인합니다.

데이터 모델과 앱의 복잡성에 따라 파티션 키는 다음 중 하나일 수 있습니다.

  • 각 문서에 이미 존재하며 데이터를 논리적으로 분할하는 속성입니다. 예를 들어, 모든 문서가 특정 사용자에게만 비공개인 앱을 생각해 보겠습니다. 사용자의 ID 값을 owner_id 필드에 저장한 다음, 이를 파티션 키로 사용할 수 있습니다.

  • 데이터를 분할하기 위해 생성하는 합성 속성(예: _partition). 앱에 내추럴 파티션 키가 포함되어 있지 않은 경우 이 방법을 사용할 수 있습니다.

객체에 파티션 키를 필수 또는 선택 사항으로 설정할 수 있습니다. App Services는 파티션 키를 포함하지 않는 모든 객체를 기본 파티션( 널 파티션)에 매핑합니다.

파티션 키를 선택할 때 다음 사항을 고려하세요.

  • 파티션 키는 String, ObjectID, Long, UUID 중 한 가지 유형이어야 합니다.

  • App Services 클라이언트는 파티션 값을 직접 수정해서는 안 됩니다. 클라이언트가 파티션 키로 수정할 수 있는 필드는 사용할 수 없습니다.

  • 파티션 키는 동기화된 모든 문서에서 동일한 필드 이름을 사용합니다. 파티션 키는 객체 모델의 필드 이름과 충돌해서는 안 됩니다.

예시

다음 스키마는 자연 및 가상 파티션 키를 보여 줍니다.

  • owner_id 필드는 이미 앱의 데이터 모델에 포함되어 있으므로 자연 키입니다.

  • _partition 필드는 파티션 키 역할을 하는 것이 유일한 목적이므로 합성 키입니다.

앱은 파티션 키를 하나만 지정할 수 있지만 사용 사례에 따라 다음 필드 중 하나라도 작동할 수 있습니다.

{
"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" }
}
}
}

앱의 파티션 키는 동기화가 허용된 앱의 데이터 모델에서 핵심적인 부분입니다. 동기화 구성에서 파티션 키를 설정하면 나중에 키 필드를 다시 할당할 수 없습니다. 파티션 키를 변경해야 하는 경우 동기화를 종료해야 합니다. 그런 다음 새 파티션 키를 활성화하여 다시 허용할 수 있습니다. 하지만 이를 위해서는 모든 클라이언트 애플리케이션을 재설정하고 데이터를 새로운 영역으로 동기화해야 합니다.

경고

동기화 종료 후 동기화 복원하기

Atlas Device Sync를 종료했다가 다시 활성화하면 클라이언트가 더 이상 동기화할 수 없습니다. 동기화를 복원하려면 클라이언트가 클라이언트 재설정 핸들러를 구현해야 합니다. 이 핸들러는 동기화되지 않은 변경 사항을 삭제하거나 복구를 시도할 수 있습니다.

  • 클라이언트 재설정 - Flutter SDK

  • 클라이언트 재설정 - Java SDK

  • Client Reset - Kotlin SDK

  • 클라이언트 재설정 - .NET SDK

  • 클라이언트 재설정 - 노드 SDK

  • 클라이언트 재설정 - React Native SDK

  • 클라이언트 재설정 - Swift SDK

파티션 값은 지정된 문서에 대한 파티션 키 필드의 값입니다. 동일한 파티션 값을 가진 문서는 동일한 파티션에 속합니다. 이들은 동일한 영역 파일에 동기화되며 사용자 수준의 데이터 액세스 권한을 공유합니다.

파티션 값은 해당 동기화된 영역의 식별자입니다. 파티션 값은 클라이언트에서 동기화된 영역으로 열 때 지정합니다. Atlas에서 파티션 값을 변경하면 App Services는 변경 사항을 두 가지 작업으로 해석합니다.

  • 이전 파티션에서 삭제하기.

  • 새 파티션에 삽입합니다.

경고

문서의 파티션 값을 변경하면 객체에 대한 클라이언트 사이드 동기화되지 않은 변경 사항이 손실됩니다.

파티션 기반 동기화를 활성화하는 데 필요한 사항:

  • App Services App. 앱을 만드는 방법을 알아보려면 앱 만들기를 참조하세요.

  • 연결된 Atlas 데이터 소스입니다. 데이터 소스를 추가하는 방법을 알아보려면 데이터 소스 연결을 참조하세요.

1

Device Sync 규칙을 정의하고 애플리케이션 에 대해 Device Sync 를 활성화 하려면 왼쪽 탐색 메뉴를 통해 Device Sync 구성 화면으로 이동합니다.

참고

동기화 규칙을 변경할 수 없음

Device Sync를 활성화하는 동시에 Device Sync 규칙을 정의할 수 있습니다. Device Sync를 활성화한 후에는 Device Sync를 종료하고 새 규칙으로 활성화해야 앱의 Device Sync 규칙을 변경할 수 있습니다.

2

애플리케이션에서 단일한 연결된 클러스터에 대해 Device Sync를 활성화할 수 있습니다. 사용할 cluster를 결정한 다음 Select a Cluster To Sync 드롭다운 메뉴에서 선택합니다.

클러스터 선택 드롭다운 메뉴
3

Device Sync 파티션 키는 각 문서를 클라이언트 사이드 영역에 매핑하는 모든 동기화된 문서의 필드입니다. Device Sync 규칙은 파티션 수준에서 적용되므로 데이터 모델과 액세스 패턴을 고려하는 것이 특히 중요합니다. 파티션 키 및 파티션 키 선택에 대한 자세한 내용은 파티션을 참조하세요 .

참고

파티션 키는 필수 또는 선택 사항일 수 있습니다. 파티션 키 필드가 선택 사항인 경우, 파티션 키를 제외하거나 파티션 키 값이 null인 모든 MongoDB 문는 널 파티션으로 전송됩니다. 파티션 키 필드가 필수 사항인 경우, Device Sync는 유효한 파티션 키 값이 없는 모든 MongoDB 문서를 무시합니다. We recommend a required partition key unless you want to Device Sync pre-existing data with invalid or missing partition values from a MongoDB collection.

4

Define Permissions 섹션에서는 앱 서비스가 지정된 파티션의 데이터에 대한 사용자의 읽기 및 쓰기 권한을 결정하기 위해 동적으로 평가하는 JSON 표현식을 정의할 수 있습니다.

Device Sync 규칙 표현식은 영역을 연 사용자로 확인되는 %%user와 영역의 파티션 키 값으로 확인되는 %%partition에 액세스할 수 있습니다. %function를 비롯한 연산자를 사용하여 더 복잡한 케이스를 처리할 수도 있습니다. 예를 보려면 역할 기반 권한 항목을 참조하세요.

특정 파티션에 대한 사용자의 읽기 및 쓰기 권한을 결정하는 방법을 결정한 후에는 ReadWrite 입력에서 해당 JSON 표현식을 정의합니다.

5

Advanced Configuration 섹션을 확장합니다.

App Services 앱은 기본적으로 활성화된 고급 최적화 기능을 제공합니다.

클라이언트 가 오프라인 상태일 수 있는 시간을 변경하려면 Advanced Configuration 섹션에서 변경할 수 있습니다.

6

동기화된 클러스터의 규칙을 구성했으니 이제 클라이언트 애플리케이션의 Device Sync를 켜기만 하면 됩니다. Enable Sync를 클릭하고 표시되는 권장 사항을 기록한 후 선택한 내용을 확정하세요.

1

MongoDB Atlas Admin API 키를 사용하여 CLI에 로그인합니다.

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

앱 구성 파일의 로컬 복사본을 가져옵니다. 최신 버전의 앱을 받으려면 다음 명령을 실행합니다.

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

UI에서 또는 Admin API를 사용하여 애플리케이션 구성 파일의 사본을 내보낼 수도 있습니다. 방법을 알아보려면 앱 내보내기를 참조하세요.

3

애플리케이션에서 연결된 단일 클러스터에 대한 동기화를 활성화할 수 있습니다.

App Services 앱에는 동기화 구성 파일을 찾을 수 있는 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>
}
4

동기화 파티션 키는 각 문서를 클라이언트 사이드 영역에 매핑하는 모든 동기화된 문서의 필드입니다. 동기화 규칙은 파티션 수준에서 적용되므로 데이터 모델과 액세스 패턴을 고려하는 것이 특히 중요합니다. 파티션 키 및 파티션 키 선택에 대한 자세한 내용은 파티션을 참조하세요 .

참고

파티션 키 는 필수 또는 선택 사항일 수 있습니다. 파티션 키 필드 가 선택 사항인 경우, 파티션 키를 제외하거나 파티션 키 파티션 키 이 null인 모든 MongoDB 문서는 널 파티션 으로 전송됩니다. 파티션 키 필드 가 필수인 경우 Device Sync 는 유효한 파티션 키 값이 없는 모든 MongoDB 문서를 무시합니다. MongoDB 컬렉션 에서 유효하지 않거나 누락된 파티션 값으로 기존 데이터를 동기화 하려는 경우가 아니라면 필수 파티션 키 를 권장합니다.

사용할 필드 를 결정한 후에는 다음과 같이 key 필드의 파티션 키 필드 이름과 type 필드 의 파티션 키 유형으로 sync.partition 를 업데이트 필드.

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

App Services 를 사용하면 사용자가 영역 을 열 때마다 동적으로 평가하여 사용자에게 파티션의 데이터에 대한 읽기 또는 쓰기 (write) 권한이 있는지 확인하는 JSON 표현식 을 정의할 수 있습니다.

동기화 규칙 표현식은 영역 을 연 사용자로 확인되는 %%user 및 영역 의 파티션 키 값으로 확인되는 %%partition 에 액세스 할 수 있습니다. %function 등의 연산자를 사용하여 더 복잡한 경우를 처리하다 할 수도 있습니다. 예제는 동기화 권한을 참조하세요.

특정 파티션에 대한 사용자의 읽기 및 쓰기 (write) 권한을 결정하는 방법을 결정한 후에는 partition.permissionsreadwrite 필드에 해당 JSON 표현식을 다음과 같이 정의합니다.

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

동기화는 동기화 성능을 최적화하고 클라이언트 의 데이터 복구 프로세스 를 개선할 수 있는 기능을 활성화 합니다. 이러한 기능은 추가 설정으로 표시됩니다.

  • client_max_offline_days

  • is_recovery_mode_disabled

client_max_offline_days 에 숫자 값을 설정하다 수 있습니다. App Services UI 를 통해 동기화를 활성화 하는 경우 기본값 은 30 30 입니다.

자세한 내용은 클라이언트 최대 오프라인 시간을 참조하세요.

복구 모드를 사용하면 클라이언트 재설정 이 발생할 때 동기화가 아직 동기화되지 않은 데이터 복구를 시도할 수 있습니다. App Services UI 를 통해 동기화를 활성화 하면 복구 모드가 기본값 활성화됩니다. 자동 클라이언트 재설정 처리를 위해 복구 모드를 활성화하는 것이 좋습니다. 복구 모드 를 비활성화했다가 다시 활성화하려면 is_recovery_mode_disabledfalse 로 설정하다 합니다.

자세한 내용은 동기화되지 않은 변경 사항 복구를 참조하세요.

{
"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
}
7

이제 읽기 및 쓰기 (write) 권한을 포함한 동기화 구성을 정의했으므로 변경 사항을 배포 하여 데이터 동기화 및 동기화 규칙 적용을 시작할 수 있습니다.

변경 사항을 배포하려면 App Services App으로 앱 구성을 가져옵니다.

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

애플리케이션에서 연결된 단일 클러스터에 대한 동기화를 활성화할 수 있습니다.

동기화를 구성하려면 클러스터의 서비스 구성 파일이 필요합니다. 관리자 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>'

동기화를 활성화하기 위해 구성을 업데이트해야 하는 서비스를 식별합니다. 앱을 구성할 때 기본 이름을 수락한 경우 이 서비스는 namemongodb-atlas 이고 typemongodb-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>
}
...
}
2

동기화 파티션 키는 각 문서를 클라이언트 사이드 영역에 매핑하는 모든 동기화된 문서의 필드입니다. 동기화 규칙은 파티션 수준에서 적용되므로 데이터 모델과 액세스 패턴을 고려하는 것이 특히 중요합니다. 파티션 키 및 파티션 키 선택에 대한 자세한 내용은 파티션을 참조하세요 .

관리자 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 문서는 널 파티션 으로 전송됩니다. 파티션 키 필드 가 필수인 경우 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>
}
...
}
3

App Services 를 사용하면 사용자가 영역 을 열 때마다 동적으로 평가하여 사용자에게 파티션의 데이터에 대한 읽기 또는 쓰기 (write) 권한이 있는지 확인하는 JSON 표현식 을 정의할 수 있습니다.

동기화 규칙 표현식은 영역 을 연 사용자로 확인되는 %%user 및 영역 의 파티션 키 값으로 확인되는 %%partition 에 액세스 할 수 있습니다. %function 등의 연산자를 사용하여 더 복잡한 경우를 처리하다 할 수도 있습니다. 예제는 동기화 권한을 참조하세요.

특정 파티션에 대한 사용자의 읽기 및 쓰기 (write) 권한을 결정하는 방법을 결정한 후에는 sync.partition.permissionsreadwrite 필드에 해당 JSON 표현식을 정의합니다.

{
...
"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>
}
...
}
4

동기화는 동기화 성능을 최적화하고 클라이언트 데이터 복구 프로세스 를 개선할 수 있는 기능을 활성화 합니다. 이러한 기능은 추가 설정으로 표시됩니다.

  • client_max_offline_days

  • is_recovery_mode_disabled

client_max_offline_days 에 숫자 값을 설정하다 수 있습니다. App Services UI 를 통해 동기화를 활성화 하는 경우 기본값 은 30 30 입니다.

자세한 내용은 클라이언트 최대 오프라인 시간을 참조하세요.

복구 모드를 사용하면 클라이언트 재설정 이 발생할 때 동기화가 동기화되지 않은 데이터 복구를 시도할 수 있습니다. App Services UI 를 통해 동기화를 활성화 하면 복구 모드가 기본값 활성화됩니다. 자동 클라이언트 재설정 처리를 위해 복구 모드를 활성화하는 것이 좋습니다. 복구 모드를 활성화 하려면 is_recovery_mode_disabledfalse 로 설정하다 합니다.

자세한 내용은 동기화되지 않은 변경 사항 복구를 참조하세요.

{
...
"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
}
...
}
5

이제 읽기 및 쓰기 (write) 권한을 포함한 동기화 구성을 정의했으므로 변경 사항을 배포 하여 데이터 동기화 및 동기화 규칙 적용을 시작할 수 있습니다.

변경 사항을 배포 하려면 동기화 구성으로 클러스터 구성을 업데이트하는 관리자 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

사용자가 클라이언트 앱에서 동기화된 영역을 열 때마다 App Services는 앱의 규칙을 평가하고 사용자에게 파티션에 대한 읽기 및 쓰기 권한이 있는지 확인합니다. 사용자는 영역의 데이터를 동기화하고 읽으려면 읽기 권한이 있어야 하며 객체를 만들거나 수정 또는 삭제하려면 쓰기 권한이 있어야 합니다. 쓰기 권한은 읽기 권한을 의미하므로 사용자에게 쓰기 권한이 있으면 읽기 권한도 갖게 됩니다.

동기화 규칙은 특정 파티션에 적용되며 파티션 키를 통해 앱의 데이터 모델에 연결됩니다. 스키마를 설계할 때 다음 동작을 고려하여 적절한 데이터 액세스 세분성을 유지하고 중요한 정보를 실수로 유출하지 않도록 합니다.

  • 동기화 규칙은 사용자에 따라 동적으로 적용됩니다. 한 사용자는 파티션에 대한 전체 읽기 & 쓰기 권한이 있는 반면, 다른 사용자는 읽기 권한만 있거나 파티션에 전혀 액세스할 수 없을 수 있습니다. JSON 표현식을정의하여 이러한 권한을 제어합니다.

  • 동기화 규칙은 파티션의 모든 객체에 동일하게 적용됩니다. 특정 파티션에 대한 읽기 또는 쓰기 권한이 있는 사용자는 파티션에 있는 모든 객체의 모든 동기화 필드를 읽거나 수정할 수 있습니다.

  • 쓰기 권한에는 읽기 권한이 필요하므로 파티션에 대한 쓰기 권한이 있는 사용자는 정의된 읽기 권한 규칙에 관계없이 읽기 권한도 함께 가집니다.

App Services는 각 파티션의 데이터를 보호하기 위해 사용자별 동적 읽기 및 쓰기 권한을 시행합니다. 지정된 사용자가 지정된 파티션의 데이터에 대한 읽기 또는 쓰기 액세스 권한이 있는지 여부를 제어하는 JSON 규칙 표현식을 사용하여 권한을 정의합니다. App Services는 사용자가 동기화된 영역을 열 때마다 사용자의 권한을 평가합니다.

규칙 표현식은 %%partition%%user와 같은 JSON 확장을 사용하여 요청의 컨텍스트에 따라 사용자의 권한을 동적으로 결정할 수 있습니다.

지정된 파티션에 대한 읽기 권한이 있는 사용자는 해당 동기화 영역에 있는 모든 객체의 모든 필드를 볼 수 있습니다. 읽기 권한은 사용자가 데이터를 수정하는 것을 허용하지 않습니다.

특정 파티션에 대한 쓰기 권한이 있는 사용자는 해당 동기화 영역에 있는 모든 객체의 필드 값을 수정할 수 있습니다. 쓰기 권한에는 읽기 권한이 필요하므로 데이터를 수정할 수 있는 모든 사용자는 수정 전후에 해당 데이터를 볼 수도 있습니다.

중요

관계는 파티션에 걸쳐 있을 수 없습니다.

파티션 기반 동기화 를 사용하는 앱에서 객체 는 동일한 파티션에 있는 다른 객체와만 관계를 가질 수 있습니다. 파티션 키 값이 일치하는 한 객체는 서로 다른 데이터베이스 및 컬렉션(동일한 클러스터 내)에 존재할 수 있습니다.

읽기 및 쓰기 권한 표현식을 파티션 전략에 적용되는 권한 전략 세트로 구성할 수 있습니다. 다음 전략은 앱에 대한 동기화 읽기 및 쓰기 권한을 정의하기 위해 취할 수 있는 일반적인 접근 방식을 간략하게 설명합니다.

모든 파티션에 대해 모든 사용자에게 적용되는 전역 권한을 정의할 수 있습니다. 이는 기본적으로 모든 사용자에게 적용되는 범용 읽기 또는 쓰기 권한을 위해 사용자별 권한을 구현하지 않기로 선택하는 것입니다.

전역 읽기 또는 쓰기 권한을 정의하려면 부울 값을 지정하거나 항상 동일한 부울 값으로 평가되는 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 값 중 하나를 가진 모든 사용자가 모든 파티션의 데이터에 대해 지정된 액세스 권한을 갖는다는 의미입니다.

사용자 지정 사용자 데이터 문서에 정의된 특정 데이터, 메타데이터 필드 또는 인증 제공자의 기타 데이터를 기반으로 사용자에게 적용되는 권한을 정의할 수 있습니다.

예시
설명
{ "%%user.custom_data.readPartitions" : "%%partition" }
이 표현식은 파티션 값이 사용자 지정 사용자 데이터의 readPartitions 필드에 나열되어 있는 경우 사용자에게 파티션에 대한 읽기 액세스 권한이 있음을 의미합니다.
{ "%%user.data.writePartitions" : "%%partition" }
이 표현식은 파티션 값이 사용자 객체의 data.writePartitions 필드에 나열되어 있는 경우 사용자에게 파티션에 대한 쓰기 권한이 있음을 의미합니다.

부울 값을 반환하는 함수를 평가하여 복잡한 동적 권한을 정의할 수 있습니다. 이는 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 collection에서 파티션에 대한 사용자 권한을 조회한 다음 사용자가 요청된 파티션에서 데이터를 읽을 수 있는지 여부를 나타내는 부울을 반환합니다.

파티션 기반 동기화 앱을 Flexible Sync로 마이그레이션하는 경우 데이터 액세스 규칙도 마이그레이션해야 합니다.

일부 파티션 기반 동기화 규칙 전략은 App Services 규칙으로 직접 변환할 수 없습니다. 다음과 같은 권한을 수동으로 마이그레이션해야 할 수도 있습니다.

  • %function 연산자를 사용하세요.

    함수 규칙은 flexible sync(Flexible Sync)와 호환되지 않으며 마이그레이션할 수 없습니다.

  • %%partition 확장.

    App Services 규칙에 %%partition에 해당하는 확장이 없으므로 마이그레이션할 수 없습니다.

  • %or, %not, %nor, %and 확장을 사용합니다.

    이러한 권한은 작동할 가능성이 있지만, 예상되는 동작을 확인하기 위해 테스트해야 하는 미묘한 차이가 있습니다. 마이그레이션하는 앱에서는 새 권한을 테스트할 수 없습니다. 수동으로 마이그레이션한 권한을 테스트하려면 새 앱이 필요합니다.

지원되는 모든 확장은 Flexible Sync 호환 확장 목록을 참조하세요.

권한 작업 방법에 대한 자세한 내용은 Device Sync 권한 가이드를 참조하세요.

파티션 전략은 객체를 파티션으로 나누는 키/값 패턴입니다. 사용 사례에 따라 다른 파티션 전략이 필요합니다. 동일한 앱 내에서 파티션 전략을 구성하여 더 큰 전략을 구성할 수 있습니다. 이를 통해 임의로 복잡한 사용 사례를 처리할 수 있습니다.

어떤 전략을 사용할지는 앱의 데이터 모델과 액세스 패턴에 따라 달라집니다. 공개 데이터와 비공개 데이터가 모두 포함된 앱을 생각해 보세요. 공지 사항과 같은 일부 데이터를 공개 파티션에 넣을 수 있습니다. 개인 정보와 같은 다른 데이터는 권한이 있는 사용자에게만 제공하도록 제한할 수 있습니다.

파티션 전략을 개발할 때는 다음 사항을 고려합니다.

  • 데이터 보안: 사용자는 데이터의 하위 세트에 대해 다양한 읽기 및 쓰기 액세스 권한이 필요할 수 있습니다. 문서 유형에 대해 사용자에게 필요한 권한을 고려합니다. 사용자는 파티션의 모든 문서에 대해 동일한 권한을 갖습니다.

  • 저장 용량: 클라이언트 앱은 일부 장치 및 플랫폼에서 장치 내 저장소가 제한될 수 있습니다. 파티션 전략은 스토리지 제한을 고려해야 합니다. 사용자가 자신의 디바이스에 동기화된 데이터를 저장할 수 있는지 확인합니다.

전략 결합

쿼리 문자열을 값으로 사용하는 _partition과 같은 파티션 키 이름을 사용할 수 있습니다. 이를 통해 동일한 앱에서 여러 전략을 사용할 수 있습니다. 예시:

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

함수 및 규칙 표현식을 사용하여 문자열을 구문 분석할 수 있습니다. 동기화는 결합된 전략을 기반으로 사용자가 파티션에 액세스할 수 있는지 여부를 결정할 수 있습니다.

파이어호스 파티션 전략은 모든 문서를 단일 파티션으로 그룹화합니다. 이 구조를 사용하면 모든 사용자가 앱의 모든 데이터를 자신의 기기에 동기화할 수 있습니다. 이 접근 방식은 기능적으로 데이터를 분할하지 않기로 결정한 것입니다. 이는 기본 애플리케이션이나 소규모 공개 데이터 세트에 적합합니다.

  • 데이터 보안. 모든 데이터는 파티션을 사용하는 영역이 있는 클라이언트에게 공개됩니다. 사용자에게 파티션에 대한 읽기 또는 쓰기 액세스 권한이 있는 경우 모든 문서를 읽거나 쓸 수 있습니다.

  • 저장 용량. 모든 사용자는 파티션의 모든 문서를 동기화합니다. 모든 데이터는 가장 제한적인 저장 용량 한도 내에 들어맞아야 합니다. 이 전략은 데이터 세트가 작고 빠르게 증가하지 않는 경우에만 사용하세요.

파이어호스를 생성하는 한 가지 방법은 파티션 키를 선택적 필드로 설정하는 것입니다. 어떤 문서에도 이 필드의 값을 포함하지 마세요. App Services는 파티션 값을 포함하지 않는 모든 문서를 널 파티션에 매핑합니다.

정적 파티션 값을 설정할 수도 있습니다. 이 경우 사용자 또는 데이터에 따라 파티션 값이 변경되지 않습니다. 예를 들어 모든 클라이언트의 영역은 "MyPartitionValue" 파티션 값을 사용할 수 있습니다.

예시

사용자가 앱을 통해 고등학교 야구 경기의 스코어와 통계를 검색할 수 있습니다. gamesteams 컬렉션에 있는 다음 문서를 고려하세요.

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 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" }
]

사용자 파티션 전략은 각 사용자의 비공개 문서를 그룹화합니다. 이러한 문서는 해당 사용자 전용 파티션으로 이동합니다. 이는 각 문서에 소유자가 있고 다른 사람이 해당 데이터를 필요로 하지 않을 때 작동합니다. 소유자를 식별하는 사용자 이름 또는 ID는 자연 파티션 키를 만듭니다.

  • 데이터 보안. 사용자 파티션의 데이터는 특정 사용자에게만 해당됩니다. 여기에는 해당 사용자의 비공개 정보가 포함될 수 있습니다. 각 사용자는 자신의 파티션만 동기화합니다. 다른 사용자는 파티션의 문서에 액세스할 수 없습니다.

  • 저장 용량. 각 사용자는 자신의 파티션에 있는 데이터만 동기화합니다. 데이터는 장치의 저장 공간 제약 조건에 맞아야 합니다. 각 사용자가 관리 가능한 양의 데이터를 가진 경우에만 이 전략을 사용하세요.

예시

음악 스트리밍 앱은 각 사용자의 재생 목록 및 노래 등급에 대한 데이터를 저장합니다. playlistsratings 컬렉션에 있는 다음 문서를 참조하십시오.

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 필드가 포함됩니다. 이는 사용자 파티션 전략에 적합한 파티션 키입니다. 문서를 개별 사용자에게 자연스럽게 매핑합니다. 이렇게 하면 각 장치의 데이터가 해당 장치 사용자의 재생 목록과 등급으로 제한됩니다.

  • 사용자는 사용자 영역에 대한 읽기 및 쓰기 액세스 권한이 있습니다. 여기에는 사용자가 만든 재생 목록과 노래에 부여한 평가가 포함됩니다.

  • 모든 사용자는 파티션 값 PUBLIC의 영역에 대한 읽기 액세스 권한이 있습니다. 여기에는 모든 사용자가 사용할 수 있는 재생 목록이 포함됩니다.

이 전략은 컬렉션을 다음 영역에 매핑합니다.

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: [ ... ] }
]

팀 파티션 전략은 사용자 팀이 공유하는 비공개 문서를 그룹화하는 것입니다. 팀에는 매장 위치의 직원 또는 밴드 멤버가 포함될 수 있습니다. 각 팀에는 해당 그룹에 해당하는 파티션이 있습니다. 팀의 모든 사용자는 팀 문서에 대한 액세스 권한과 소유권을 공유합니다.

  • 데이터 보안. 팀 파티션의 데이터는 지정된 팀에만 적용됩니다. 여기에는 팀에는 비공개이지만 팀원에게는 그렇지 않은 데이터가 포함될 수 있습니다. 각 사용자는 자신이 속한 팀의 파티션을 동기화합니다. 팀에 속하지 않은 사용자는 팀 파티션에 있는 문서에 액세스할 수 없습니다.

  • 저장 용량: 각 사용자는 자신의 팀의 데이터만 동기화합니다. 사용자 팀의 데이터는 해당 장치의 저장 용량 제한에 맞아야 합니다. 사용자가 관리 가능한 수의 팀에 속해 있는 경우 이 전략을 사용합니다. 사용자가 여러 팀에 소속되어 있는 경우 통합된 영역에 많은 데이터가 포함될 수 있습니다. 한 번에 동기화할 수 있는 팀 파티션 수를 제한해야 할 수도 있습니다.

예시

앱을 통해 사용자는 다른 사용자와 협업할 프로젝트를 만들 수 있습니다. projectstasks 컬렉션에 있는 다음 문서를 참조하십시오.

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 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로 이러한 채널을 식별할 수 있습니다.

  • 데이터 보안. 채널 파티션의 데이터는 주제 또는 영역에 한정되어 있습니다. 사용자는 이러한 채널에 액세스하도록 선택할 수 있습니다. 채널 하위 집합에 대한 사용자 액세스를 제한할 수 있습니다. 사용자가 채널에 완전히 액세스하지 못하도록 차단할 수 있습니다. 사용자에게 채널에 대한 읽기 또는 쓰기 권한이 있는 경우 파티션의 모든 문서에 액세스할 수 있습니다.

  • 저장 용량. 사용자는 허용된 모든 채널에서 데이터를 동기화하도록 선택할 수 있습니다. 사용자 채널의 모든 데이터는 해당 장치의 저장 용량 제한에 맞아야 합니다. 이 전략을 사용하여 공개 또는 반 비공개 데이터 세트를 분할합니다. 이 전략은 저장 용량 제한에 맞지 않는 데이터 세트를 분할합니다.

예시

앱을 사용하면 사용자가 주제에 따라 채팅방을 만들 수 있습니다. 사용자는 관심 있는 주제에 대한 채널을 검색하고 참여할 수 있습니다. chatroomsmessages 컬렉션에 있는 다음 문서를 참조하십시오.

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에 저장합니다.

    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 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 및 {1} 컬렉션에 있는 다음 문서를 고려하세요.

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 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: [ ... ] }
]

버킷 파티션 전략은 문서를 범위별로 그룹화합니다. 문서가 차원을 따라 범위가 지정되면 파티션에 하위 범위가 포함됩니다. 시간 기반 버킷 범위를 고려하세요. 문서가 버킷 범위를 벗어나면 문서를 새 파티션으로 옮기는 트리거를 실행합니다.

  • 데이터 보안. 사용자가 특정 버킷만 읽거나 쓰도록 제한합니다. 데이터가 버킷 간에 이동할 수 있습니다. 가능한 모든 버킷에 걸쳐 문서에 대한 액세스 권한을 고려합니다.

  • 저장 용량. 저장 요구 사항은 각 버킷의 크기와 사용 패턴에 따라 다릅니다. 사용자가 액세스해야 하는 버킷을 고려합니다. 디바이스의 저장 제약 조건에 맞게 버킷 크기를 제한합니다. 사용자가 많은 버킷을 동기화하는 경우 더 작은 버킷으로 분할합니다. 이렇게 하면 불필요한 데이터 동기화를 방지할 수 있습니다.

예시

IoT 앱은 센서 판독값을 초당 여러 번 실시간으로 보여 줍니다. 버킷은 판독값이 들어온 이후 초 단위로 파생됩니다. readings collection의 다음 문서를 참조하세요.

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 필드가 포함됩니다. 이 필드는 문서를 특정 시간 범위에 매핑합니다. 사용자의 디바이스에는 사용자가 보고 있는 창에 대한 센서 판독값만 포함됩니다.

  • 사용자는 모든 시간 버킷의 센서 판독값에 대한 읽기 액세스 권한이 있습니다.

  • 센서는 쓰기 액세스 권한이 있는 클라이언트 앱을 사용하여 판독값을 업로드합니다.

이 전략은 컬렉션을 다음 영역에 매핑합니다.

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: { ... } }
]

데이터 수집은 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와 이전 파티션 기반 동기화라는 두 가지 동기화 모드가 있습니다.

파티션 기반 동기화 구성을 위한 유효 옵션:

  • "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는 동기화된 각 유형에 대한 스키마를 자동으로 생성하고 각 객체 유형을 데이터베이스 내의 collection에 매핑합니다.
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에서는 사용자가 객체 또는 객체의 속성을 수정할 수 없습니다. 쓰기 권한에는 읽기 권한이 필요합니다. 사용자는 읽을 수 없는 문서에 쓸 수 없습니다.
last_disabled
Number
동기화가 마지막으로 일시 중지되거나 비활성화된 날짜와 시간으로 유닉스 시간(1970년 1월 1일 00:00:00 UTC) 이후의 시간(초)으로 표시됩니다.
client_max_offline_days
Number
일부 클라이언트가 이전 버전의 영역에서 동기화해야 하는 메타데이터를 적극적으로 정리하기 전에 백엔드 압축 프로세스가 대기하는 시간을 제어합니다.
is_recovery_mode_disabled
Boolean
false인 경우 애플리케이션에 대해 복구 모드가 활성화됩니다. 기능이 활성화된 상태에서 이 기능을 지원하는 Realm SDK는 클라이언트 재설정을 수행할 때 동기화되지 않은 변경 사항을 복구하려고 시도합니다. 복구 모드는 기본적으로 활성화되어 있습니다.

파티션 기반 Device Sync 구성을 변경하려면 Device Sync를 종료하고 Device Sync를 다시 활성화해야 합니다. Atlas Device Sync를 다시 활성화하는 동안 새 파티션 키를 지정하거나 읽기/쓰기 권한을 변경할 수 있습니다. Device Sync를 종료하고 다시 활성화하는 동안 Device Sync 구성을 변경하면 클라이언트 재설정이 트리거하됩니다. 클라이언트 재설정 처리에 대해 자세히 알아보려면 클라이언트 재설정 설명서를 참조하세요.

에서 파티션 기반 동기화를 사용할 때 다음 오류가 발생할 수 있습니다.

오류 이름
설명
ErrorIllegalRealmPath

이 오류는 클라이언트가 잘못된 유형의 파티션 값을 사용하여 영역을 열려고 했음을 나타냅니다. 예를 들어 '잘못된 영역 파티션에 대한 바인딩 시도: 예상 파티션에 객체 ID 유형이 있어야 하는데 문자열이 발견되었습니다'라는 오류 메시지가 표시될 수 있습니다.

이 오류를 복구하려면 영역을 여는 데 사용된 파티션 값 유형이 Device Sync 구성의 파티션 키 유형과 일치하는지 확인해야 합니다.

Atlas Device Sync는 동기화된 앱의 Atlas 클러스터 공간을 사용하여 동기화를 위한 메타데이터를 저장합니다. 여기에는 각 영역의 변경 내역이 포함됩니다. Atlas App Services는 Atlas 클러스터에서 이 공간 사용량을 최소화합니다. 동기화에 필요한 시간과 데이터를 줄이려면 메타데이터를 최소화해야 합니다.

파티션 기반 동기화를 사용하는 앱은 백엔드 압축을 수행하여 Atlas 클러스터에 저장되는 메타데이터의 양을 줄입니다. 백엔드 압축은 파티션 기반 동기화를 사용하는 모든 앱에 대해 자동으로 실행되는 유지 관리 프로세스입니다. 백엔드는 압축을 통해 불필요한 변경 집합 메타데이터를 제거하여 영역의 기록을 최적화합니다. 이 프로세스는 나중에 새로운 명령어로 효과를 덮어쓰는 모든 명령어를 제거합니다.

예시

다음 영역 기록을 고려하세요.

원본 기록
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

참고

파티션 기반 동기화 는 백엔드 압축 을 사용하여 Atlas 에 저장된 Device Sync 기록을 줄입니다. Flexible Sync는 트리밍클라이언트 최대 오프라인 시간을 통해 이를 달성합니다.

돌아가기

whoami