코우치베이스 모바일

에지 애플리케이션을 위한 Couchbase Mobile의 스코프 및 컬렉션 지원

12 분 읽기

모바일 및 엣지 컴퓨팅 솔루션을 위한 Couchbase Lite 및 Sync Gateway가 포함된 Couchbase Mobile 3.1의 정식 출시(GA)를 발표하게 되어 기쁩니다. 이번 릴리스는 자체 관리형 배포를 위해 Couchbase Mobile에서 스코프(scopes) 및 컬렉션(collections)에 대한 클라우드 대 엣지(cloud-to-edge) 지원을 도입하는 중요한 릴리스입니다. 출시는 카우치베이스 서비스 7.0, 스코프와 컬렉션은 데이터를 논리적으로 격리하고 여러 세분성 수준에서 독립적인 앱 라이프사이클 관리를 시행할 수 있는 기능을 제공합니다.

Couchbase Lite 및 Sync Gateway 3.1 릴리스를 통해 개발자는 모바일 및 엣지 앱 내에서 스코프와 컬렉션의 이점을 활용할 수 있습니다. 이 게시물에서는 몇 가지 전형적인 사용 사례의 맥락에서 스코프와 컬렉션 사용의 이점에 대해 설명하겠습니다. 이 게시물은 3.1 릴리스의 핵심 기능에 초점을 맞추고 있지만, 다른 개선 사항 및 버그 수정에 대해 알아보려면 플랫폼별 릴리스 노트를 참조하시기 바랍니다.

이 게시글은 여러분이 Couchbase Mobile의 기본 개념에 익숙하다고 가정합니다. Couchbase Mobile을 처음 접하신다면, 다음을 확인해 보세요. 개요.

지금 다운로드하세요!

Couchbase Lite 및 Sync Gateway 3.1의 새로운 기능을 평가하기 시작하는 방법은 다음과 같습니다:

스코프 및 컬렉션 사용 사례

범위와 컬렉션의 이점은 실제 활용 사례를 통해 논의하는 것이 가장 좋습니다. 논의되는 각 활용 사례에 대해 버킷/데이터베이스 수준의 솔루션을 살펴본 다음, 범위와 컬렉션을 사용하는 솔루션을 소개합니다.

간소화된 데이터 구성

개발자가 관계형 데이터베이스의 테이블과 유사한 방식으로 버킷 내에 데이터를 구조화하여 관련 데이터가 별도의 컨테이너에 그룹화되도록 하는 기능으로, 특히 관계형 데이터베이스 환경에서 마이그레이션하는 개발자에게 유용합니다.

여기 있습니다 두 가지 예시 문제를 설명하기 위해:

예시

Couchbase Mobile Multi App Example

고려해 보십시오 상품 관련 데이터와 주문 관련 데이터가 포함된 현장 주문 앱. 가 있습니다 Couchbase Lite이 활성화된 두 개의 모바일 앱, 하나는 제품용이고 하나는 주문용입니다. 제품 관련 문서 Products 모바일 앱과 동기화됩니다, 반면에 주문 관련 문서가 다음으로 동기화됩니다. 주문 모바일 앱. 제품 모바일 앱의 앱 사용자는 제품 관련 데이터만 읽을 수 있는 반면, 주문 모바일 앱의 앱 사용자는 주문 관련 데이터를 읽고 쓸 수 있습니다.

 

 

 

 

해결책: 버킷 기반

Couchbase - data model bucket

  • 제품 및 주문 데이터는 단 하나의 버킷에.
  • 버킷에는 12가지 문서 유형이 있습니다. A 문서 유형 필드는 논리적으로 그룹화하는 데 사용됩니다 상품 관련 및 주문 관련 문서.
  • 앱 사용자는 버킷 수준에서 정의됩니다.
  • 동기화 함수는 버킷 수준에서 정의되며 복잡합니다.. 접근 제어 규칙은 다음을 기반으로 합니다. 문서 유형 그리고 채널 ~를 위해 정의된 문서 유형 어떤 사용자가 문서의 어떤 하위 집합에 접근할 수 있는지 제어합니다.
  • Products 앱에는 풀 온리 제품 문서의 복제인 반면, 주문 앱은 푸시풀 주문 관련 문서 복제.
해결책: 범위/컬렉션 기반

범위(scope)와 컬렉션(collection)을 사용하여 데이터를 체계적으로 정리하고 액세스 제어 정책을 단순화하세요. 

example1.1-scopes

  • Segregate products and orders related documents into two scopes within a single bucket.
  • Instead of a 문서 유형 field, logically group documents of specific type into its own collection.
  • App users are then segregated by scope, so users in the products scope can only access products documents and users in the orders scope can access orders docs.
  • The sync function becomes simplified by being set at the collection level. 
  • Products 앱에는 풀 온리 replication for products scope and the Orders app has 푸시풀 replication for orders scope. 

예시

couchbase mobile

고려해 보십시오 health care app with 30 categories of data, including patients, visits, procedures, insurers, diseases, diagnosis etc.


Patients have access to their medical records via a Couchbase Lite mobile app. Some of the documents (eg. insurers) must not be synced down to the mobile app. Some of the documents (eg. profile) can be updated by the patients via the mobile app while some (like diagnosis) are read only.

 

 

 

해결책: 버킷 기반

example1.2-bucket

  • Data corresponding to the health care app is maintained in a corresponding bucket.
  • The bucket has over 30 document types. 문서 유형 field is used to logically group related documents.
  • A Sync function is defined at the bucket level and is complicated. 접근 제어 규칙은 다음을 기반으로 합니다. 문서 유형 and channels defined for 문서 유형 어떤 사용자가 문서의 어떤 하위 집합에 접근할 수 있는지 제어합니다.

Import filters are at the bucket level and complicated. Use 문서 유형 conditions to filter out documents that don’t have to be synced.

 

해결책: 범위/컬렉션 기반

범위(scope)와 컬렉션(collection)을 사용하여 데이터를 체계적으로 정리하고 액세스 제어 정책을 단순화하세요.

example1.2-scopes

  • Instead of a 문서 유형 field, logically group each document of a specific type into its own collection.
  • The Sync function is simplified and defined at the collection level. Every collection is implicitly associated with a channel and as such it is much simpler to specify read/write access to collections.
  • Import filter function is simplified and defined at the collection level. Filter out collections of documents that do not have to be imported.

 

 

확장 가능한 멀티태넌트 애플리케이션

The ability to support multi-tenant applications that do not need strict resource isolation but still require independent data lifecycle management.

예시

multi tenant Couchbase Mobile

Consider an ISV hosting an events application for 20 enterprise tenants. Every tenant has a Couchbase Lite app that can sync event data belonging to the tenant. Every tenant has a distinct set of app users who can access tenant specific data. Authenticated app users can sync data via the corresponding Couchbase Lite app for their tenant. The tenants do not require strict resource isolation.

 

해결책: 버킷 기반

example2-bucket

  • Every tenant’s data is in its own bucket.
  • Each bucket has dozens of document types. The 문서 유형 field is used to logically group related documents.
  • As the solution scales to more tenants, more buckets and subsequently, more clusters are added. This is expensive and is not scalable.
  • Every tenant has a distinct set of app users registered at the bucket level.
  • Couchbase Lite client replications are set up to sync data from the corresponding tenant’s bucket.

 

해결책: 범위/컬렉션 기반

Scopes and collections offers a scalable alternative to supporting multi-tenant apps with independent data lifecycle management.

example2-scopes

  • Each tenant has its own scope, contained in a single 이벤트 양동이.
  • Each tenant’s client application syncs data associated with the tenant’s scope.
  • Each tenant has a distinct set of app users registered at the scope level.
  • When tenants are added or removed, a scope is added to or removed from the bucket. A tenant can be taken offline without impacting other tenants.

 

 

High Application Density at the Edge

This is the ability to support large scale cloud-to-edge deployments with a number of applications at the edge. Each edge is served using a microservices based application architecture. Microservices need loose coupling so that they can be developed, deployed, and scaled independently. Data specific to a microservice is private to the microservice.

예시

inter Sync Gateway Replication

고려해 보십시오 ship-to-shore app deployment, with 20 ships each running Couchbase Mobile clusters, and a Couchbase Mobile cluster in the cloud. The Couchbase Mobile cluster on each ship powers 50 applications. Each of the applications is built using a microservices architecture. Applications running on each ship sync voyage and ship related documents with shore clusters using inter-Sync Gateway replication. Each app has a distinct set of users.

 

 

 

해결책: 버킷 기반

example3-bucket

  • Each of the microservices corresponding to the 50 edge applications running on each ship is in its own bucket. The number of applications served by a cluster is limited by the number of buckets in the cluster.
  • Inter-Sync Gateway replications between the buckets in the on-ship cluster and corresponding cloud cluster keeps the ships and shore in-sync. The result is a minimum of one ship-to-shore replication for each microservice.
  • Setup on each ship is expensive. The cost is multiplied by the number of ships and not very scalable.

 

Solution: Scopes/collections based

Scopes and collections allow bucket consolidation and a more scalable and cost-effective alternative to bucket based solution.

example3-scopes

 

  • Each app is associated with a scope and each microservice is associated with its own collection. The result is the ability to host a large number of applications on a few clusters.
  • Inter-Sync Gateway replication between the scopes in the on-ship cluster and corresponding cloud cluster keeps the ships and shore in-sync. Instead of a replication for each microservice, replication can be set up at app level.

Data Organization and Isolation on Couchbase Lite

The ability for developers to organize and logically isolate data within a single Couchbase Lite database instance.

예시

Couchbase Mobile field app

Consider a Couchbase Lite field app used by employees of a utility company to manage their tasks when in the field. The field app regularly syncs data such as projects, infrastructure maps, etc. via Sync Gateway. The field app has a “scratchpad” like functionality that allows employees to take quick notes that they can erase without affecting other documents. These notes are temporary and local-only must not be synced to a remote server.

 

 

 

 

Solution: Bucket Based

example4-bucket

  • The bucket based solution requires two separate Couchbase Lite databases within the app; one for local-only data and one for data that is synced. 
  • A replicator is set up with the Couchbase Lite database that holds data to be synced.
  • The database level of isolation means that queries across local-only and sync data are not possible.

 

 

해결책: 범위/컬렉션 기반

Scopes and collections allow logical data isolation within a single Couchbase Lite database.

example4-scopes

  • Instead of  two Couchbase Lite databases, the use case can be supported by scopes within the same Couchbase Lite database, such that the local-only data is in one scope and data that can be synced is in another scope.
  • Data is logically isolated from each other and applications can query across the local and sync data.
  • Queries are simplified as they can be applied to a scope, avoiding need for filters. It is also easy to purge all documents in a local scope as needed.
  • The replicator is configured to sync data associated with the sync scope via Sync Gateway.

Sync Gateway Metadata Isolation

The ability to segregate application data in buckets from system metadata maintained by Sync Gateway for its internal operations.

예시

couchbase mobile SDK app

Consider an inventory management store application which allows store clerks to pull store inventory data from their Couchbase Lite embedded mobile app. Store managers use a backend web application based on Couchbase Server SDK to interface with Couchbase Server for managing inventory data.


Any updates made via the web app are synced down to the Couchbase Lite mobile app.

 

 

해결책: 버킷 기반

example5-bucket

  • Sync metadata cannot be isolated from application data using the bucket-based approach.
  • Sync gateway persists sync metadata and other database configurations in the bucket alongside application data. This data is intended to be used exclusively by Sync Gateway for its operations.
  • There are no RBAC controls that restrict access to sync metadata which is a risk. This increases the burden on the SDK-based app to ensure that it does not modify sync metadata.
  • Queries for app data need to be appropriately filtered to remove sync metadata, thereby increasing the complexity of the SDK app.
해결책: 범위/컬렉션 기반

Scopes and collections are the only option for isolating sync gateway metadata.

example5-scopes

  • System data used by Sync Gateway is maintained in _default scope/collection, where it is logically isolated from application data in user defined scopes/collections.
  • Eliminates the risk of the SDK-based app inadvertently deleting sync metadata by using scope RBAC controls to restrict access to the _default scope containing sync metadata.
  • The SDK-based app is simplified. Separation of system metadata into its own scope simplifies implementation – queries don’t need filters, and the lifecycle of app data can be managed more easily.

 

Cloud-to-Edge support for Scopes and Collections

With this release, scopes and collections are available end-to-end across the entire 코우치베이스 모바일 stack. For details, please refer to the 문서화

The figure below is a summary:

Scopes and Collections in Couchbase Mobile

  1. Data in Couchbase Server is organized within scopes and collections.
  2. A Sync Gateway database is associated with a single scope. The database can be associated with one or more collections within the scope, including all collections within the scope.
  3. A Couchbase Lite client can set up one or more replications to one or more Sync Gateway database endpoints. Each replication can sync one or all collections associated with that scope.
  4. The Couchbase Lite client can also locally persist data in a scope that is not synced to remote Sync Gateway.
  5. A Sync Gateway cluster can sync one or more scopes to another Sync Gateway cluster via inter-Sync Gateway replication protocol.
  6. A Couchbase Lite client can sync one or more scopes directly to other Couchbase Lite clients over a local network via Couchbase Lite Peer-to-Peer protocol. This can be done without the need for a cloud based control point.

호환성

Couchbase Mobile deployments upgrading to v3.1 can continue to use the bucket based model until they are ready to upgrade to scopes and collections. This also allows deployments to continue to use a bucket based model for existing apps but can take advantage of the benefits of scopes and collections for new apps.

자원

But that’s not all. There are other enhancements and API changes that are discussed in the release notes. Here are direct links to a few helpful resources. You can learn more on our What’s New page.

문서

Whitepapers

Release Notes

Hear Wayne Carter, VP of Engineer at Couchbase, talk about Scopes and Collections in Couchbase Mobile:

If you have questions or feedback, please leave a comment below or feel free to reach out to me via 트위터 또는 이메일 me.

Acknowledgement

Special thanks to Adam Fraser 그리고 Mark Gamble for their review of the blog post.

이 기사 공유하기

작가

Priya Rajagopal is a Senior Director of Product Management at Couchbase responsible for developer platforms for the cloud and the edge. She has been professionally developing software for over 20 years in several technical and product leadership positions, with 10+ years focused on mobile technologies. As a TISPAN IPTV standards delegate, she was a key contributor to the IPTV standards specifications. She has 22 patents in the areas of networking and platform security.

댓글 남기기

카우치베이스 카펠라를 시작할 준비가 되셨나요?

개발 시작하기

NoSQL을 탐색하고, 리소스를 찾아보고, 튜토리얼을 시작하려면 개발자 포털을 확인하세요.

카펠라 프리 사용하기

단 몇 번의 클릭으로 카우치베이스(Couchbase)를 직접 체험해 보세요. Capella DBaaS는 시작하기 가장 쉽고 빠른 방법입니다.

연락해

Couchbase 제품군에 대해 더 알고 싶으신가요? 저희가 도와드리겠습니다.