스키마
이 페이지의 내용
개요
스키마란 무엇인가요?
스키마는 데이터의 구조와 콘텐츠를 정의하는 JSON 객체입니다. JSON Schema 표준을 확장하는 Atlas App Services의 BSON 스키마를 사용하여 애플리케이션의 데이터 모델을 정의하고 문서가 생성, 변경 또는 삭제될 때마다 문서의 유효성을 검사할 수 있습니다.
스키마는 특정 값이 아닌 데이터 유형 을 나타냅니다. App Services는 다양한 기본 제공 스키마 유형 을 지원합니다. 여기에는 문자열, 숫자와 같은 기본 유형뿐만 아니라 객체 및 배열과 같은 구조적 유형도 포함되며, 이를 결합하여 사용자 지정 객체 유형 을 나타내는 스키마를 만들 수 있습니다.
다음 예시에서는 스키마를 준수하는 자동차 및 일부 자동차 객체에 대한 데이터의 기본 스키마를 살펴볼 수 있습니다.
{ "title": "car", "required": [ "_id", "year", "make", "model", "miles" ], "properties": { "_id": { "bsonType": "objectId" }, "year": { "bsonType": "string" }, "make": { "bsonType": "string" }, "model": { "bsonType": "string" }, "miles": { "bsonType": "number" } } }
{ "_id": ObjectId("5af712eff26b29dc5c51c60f"), "year": "2017", "make": "Honda", "model": "Civic", "miles": 117424 } { "_id": ObjectId("5af714eff24b294c5251cf04"), "year": "2020", "make": "Ford", "model": "Mustang", "miles": 13579 }
스키마를 지정하는 이유는 무엇인가요?
스키마는 애플리케이션의 데이터 모델에 대한 사양입니다. 스키마를 정의하면 App Services는 스키마를 준수하는 데이터로 작업할 수 있는 추가 도구 및 서비스를 제공합니다.
App Services는 다음과 같이 다양한 애플리케이션 서비스에서 스키마를 사용합니다.
Atlas Device Sync는 스키마를 사용하여 영역과 MongoDB Atlas 간에 데이터를 동기화합니다. App Services는 스키마를 기반으로 관용적인 SDK 객체 모델을 생성할 수도 있습니다.
데이터 액세스 규칙은 모든 요청 전후에 데이터가 스키마를 준수하는지 검증합니다. 문서 유효성 검사에 실패하면 App Services는 전체 요청을 방지하거나 롤백합니다.
스키마 정의하기
루트 수준 collection 스키마에는 해당 유형의 속성을 설명하는 추가 스키마가 포함될 수 있습니다. 각 루트 수준 스키마는 다음 형식을 갖는 object 스키마입니다.
{ "bsonType": "object", "title": "<Type Name>", "required": ["<Required Field Name>", ...], "properties": { "<Field Name>": <Schema> } }
지원되는 스키마 유형 중 하나를 사용하여 객체의 속성을 구성할 수 있습니다.
참고
앱에서 스키마를 구성하고 배포하는 방법은 스키마 정의 및 적용을 참조하세요.
App Services에서 스키마를 적용하는 방법
App Services는 MongoDB 컬렉션 스키마에 대해 해당 컬렉션에 대한 모든 쓰기 작업(삽입, 업데이트, 삭제)의 유효성을 검사합니다. 모든 요청의 전후에 모든 문서를 검사하여 모든 속성이 스키마를 준수하는지, 잘못된 변경이 발생하지 않았는지 확인합니다.
App Services는 클러스터에 쓰기를 커밋하기 전에 모든 문서 쓰기 결과를 평가하고 스키마와 비교합니다. 요청에서 쓰기 작업 결과가 스키마와 일치하지 않는 경우 App Services는 요청에 어떠한 변경 사항도 적용하지 않고 사용자에게 오류를 반환합니다.
예제
collection에는 다음과 같은 스키마가 있습니다.
{ "title": "person", "properties": { "_id": { "bsonType": "objectId" }, "name": { "bsonType": "string" } } }
모든 필드를 읽고 쓸 수 있는 권한이 있는 사용자가 특정 문서의 name 필드를 업데이트하려고 합니다. 다음 쿼리를 실행합니다.
collection.updateOne( { "_id": BSON.ObjectId("5ae782e48f25b9dc5c51c4d0") }, { "$set": { "name": 42 } } )
쿼리는 name 값을 숫자 42로 설정하려고 시도하지만, 스키마에서는 값이 string이어야 합니다. 사용자에게 문서 업데이트 권한이 있더라도 쓰기 결과가 스키마를 따르지 않기 때문에 Atlas App Services가 이 쓰기 작업을 거부합니다.
App Services 스키마 vs 내장된 스키마 유효성 검사
App Services의 스키마는 MongoDB의 기본 제공 스키마 유효성 검사와 동일하지 않습니다 . 둘 다 BSON types에 대한 추가 지원과 함께 JSON schema 표준을 사용합니다. 그러나 App Services는 클러스터의 내장 스키마를 사용하지 않으며 내장 스키마와 호환되지 않는 방식으로 클러스터와 상호 작용할 수 있습니다.
App Services 스키마 및 cluster의 내장 스키마 유효성 검사를 동시에 사용하려는 경우 다음을 고려하세요.
처음에는 클러스터의 스키마 유효성 검사 수준을 "경고"로 설정하세요. 그런 다음 활동을 모니터링하고 기존 경고를 해결하세요. 두 스키마 유효성 검사 계층이 모두 호환된다는 것이 확인되면 유효성 검사 수준을 "오류"로 업그레이드할 수 있습니다.
Device Sync를 사용하는 경우, 포함된 문서 및 포함된 문서 배열의 필수 필드 사용을 피하도록 합니다. 동기화 프로토콜은 유효한 포함된 객체 쓰기를 모든 필수 필드를 개별적으로 포함하지 않는 여러 개의 동등한 쓰기로 나눌 수 있습니다.
Device Sync를 사용하는 경우
undefined,null, 빈 배열, 필드가 없는 포함된 객체를 구분하지 않도록 합니다. 동기화 프로토콜은 이러한 값을 기능적으로 동등한 값으로 취급합니다.
두 스키마 유효성 검사 계층을 동시에 작업하는 데 도움이 필요한 경우 MongoDB 지원팀 에 문의하세요.