Couchbase 기술 공유 블로그

이번에 전문 IT채널인 TalkIT를 통해 카우치베이스 웨비나가 있었습니다. 본 방송으로 시청하지 못하신 분은 Youtube 를 통해 접하실 수 있습니다. 고 우성 PD님의 날카로운 질문과 적확한 정리도 접하실 수 있고 카우치베이스에 대한 좋은 인상을 받으실 수 있습니다. 많이 시청해 주세요.

이번 블로그는 Bucket 혹은 Collection 내 Document의 최대 보관 주기를 설정할 수 있는 Time To Live(TTL) 기능에 대해 살펴 보겠습니다.

Time To Live(TTL)에 대한 특징입니다.

• Bucket 혹은 Collection 별로 설정 가능하고 Document 별로 SDK를 통해 설정 가능
• TTL이 설정된 상태이면 신규 Document에 자동으로 설정되고 설정된 시간이 되면 해당 Document는 자동으로 삭제
• TTL의 최대 수치는 2147483648(68.096 년)
• TTL은 기본값이 0으로 비활성화 상태
• TTL 설정이 변경되더라도 그 이전에 생성된 Document는 영향을 받지 않음, 단 TTL 변경 이후에 변경된 Document는 변경된 TTL 설정으로 적용

TTL을 적용할 수 없는 시나리오

• Couchbase Eventing과 Mobile을 지원하는 Bucket에는 TTL을 설정하지 않도록 하며 만약 설정하면 시스템 오류가 발생할 수 있는 가능성

TTL에 설정된 시간에 다다른 Document에 대한 처리 프로세스는 다음과 같습니다.

• Expiry pager 프로세스가 TTL 에 설정된 시간에 다다른 Document를 삭제
• Compaction 프로세스가 실행
• 삭제된 Document는 Tombstone 영역에 임시로 보관되고 Metadata Purge 작업을 통해 Tombstone 영역도 정리, 이러한 작업은 Auto Compaction 기능을 통해 스케줄링

참고자료

https://docs.couchbase.com/server/current/learn/data/expiration.html

이번 블로그는 어느 정도까지 장애에 대응하여 데이터의 안정성을 구현할 것인지 설정하는 기능인 Durability에 대해 살펴 보겠습니다.

Coucbase Bucket에 대한 Write 작업은 다음과 같이 2 종류로 나눌 수 있습니다.

• Regular Write : Asynchronous, 센서 데이터와 같이 데이터 유실이 큰 이슈가 아닌 경우
• Durable Write : Synchronous, 금융 트랜잭션과 같이 데이터 유실 자체가 상당한 이슈인 경우
• 2 종류의 방식은 서로 Trade-Off 관계, Regular Write는 높은 Throughput을 Durable Write는 높은 데이터 안정성을 제공

Durability(Durable Write)를 적용하려면 Majority라는 개념을 이해해야 합니다. Replica 수에 따라 Commit이 필요한 Data 서비스 노드의 수가 달라질 수 있는 데, 이를 Majority라고 부릅니다.

Durability의 레벨은 다음과 같습니다.

• majority : 데이터 변경이 정해진 수의 Data 서비스 노드(노드 수는 위의 Majority 참조)의 메모리 상에 복제되는 조건
• majorityAndPersistActive : 데이터 변경이 정해진 수의 Data 서비스 노드(노드 수는 위의 Majority 참조)의 메모리 상에 복제되고 Active vBucket을 가진 Data 서비스 노드의 디스크에 저장되는 조건
• persistToMajority : 데이터 변경이 정해진 수의 Data 서비스 노드(노드 수는 위의 Majority 참조)의 메모리 상에 복제되고 복제된 모든 Data 서비스 노드의 디스크에 저장되는 조건
• 위의 3 종류의 레벨은 클라이언트에서 설정이 가능하고 Bucket에도 설정이 가능합니다.

Durability 관련 프로세스는 다음과 같습니다.

• Durable Write가 진행되는 Document를 Read하면 변경 이전의 데이터를 조회
• Durable Write가 진행되는 Document를

Durability를 적용하지 않는 Regular Write는 Active vBucket을 가진 Data 서비스 노드의 메모리에 적용되면 Replica 및 디스크 저장 여부에 상관없이 요청 성공을 반환합니다.

Durable Write의 성능을 높이려면 Couchbase Storage 설정 중 Thread를 조정하면서 최적의 값을 설정합니다. 다음 블로그를 참고하시기 바랍니다.

https://couchbase.tistory.com/16

참고자료

https://docs.couchbase.com/server/current/learn/data/durability.html

이번 블로그는 Query 및 Search 성능을 향상시킬수 있는 인덱스에 대해 살펴 보겠습니다.

Couchbase에서 제공하는 인덱스의 종류는 다음과 같습니다.

• Primary 인덱스 : Index 서비스
• Secondary 인덱스 : Index 서비스
• Full Text 인덱스 : Search 서비스
• Analytics 인덱스 : Analytics 서비스
• View 인덱스

먼저 Primary 인덱스는 특정 Collection의 Key 에 생성되는 인덱스입니다. 조건절이 포함되지 않은 간단한 Query를 위해 사용되며 운영 환경에서는 권장하지 않습니다.

Secondary 인덱스는 Document 내에 특정한 Attribute 에 생성되는 인덱스입니다. 이 인덱스는 Global Secondary Index(GSI)라고도 부릅니다. Couchbase에서 대부분의 인덱스이며 N1QL Query를 수행하는데 사용됩니다.

Full Text 인덱스는 Document 내에 텍스트 내용에 대한 검색을 위해 생성되는 인덱스입니다. 텍스트 검색, Fuzzy 검색 등에 사용됩니다.

Analytics 인덱스는 Shadow Copy에 대한 Materialized Access Path를 제공합니다. 이 인덱스는 Analytics Query 성능을 향상시키는데 사용합니다.(Select & Join)

View 인덱스는 Document 내 특정한 Attribute 및 Value를 저장하고 있는 View를 지원하는 인덱스입니다. Couchbase 7 이후로는 사라지는 기능입니다. 이 인덱스는 Secondary 인덱스로 대체될 수 있습니다.

참고자료

https://docs.couchbase.com/server/current/learn/services-and-indexes/indexes/indexes.html

이번 블로그는 Bucket 내에 Document를 구분하고 조직화할 수 있는 기능인 Scope, Collection에 대해 살펴 보겠습니다.

Collection의 특징은 다음과 같습니다.

• Bucket 내에 정의된 데이터 컨테이너로 관계형 데이터베이스의 테이블과 유사
• 클러스터 당 1,000 개까지 생성 가능
• 한 Collection 내에서 Document의 Key는 중복 불가
• Collection 별로 접근 권한 부여 가능(Role Based Access Control)
• Collection 단위로 인덱스 생성
• Collection 명 : 최대 251 문자, 알파벳(대소문자), 숫자(0-9), 심볼문자(-, %, _), 대소문자 구분(Case Sensitive)
• _default Collection : 특정 Collection을 명시하지 않은 Document 저장, 6 -> 7 Upgrade 시 이전 버전에 존재하던 Document를 저장하는 공간
• Collection 별로 Time-to-Live 설정 가능

Scope의 특징은 다음과 같습니다.

• 다수의 Collection을 그룹화 하는 기능으로 관계형 데이터베이스의 스키마와 유사
• 클러스터 당 1,000 개까지 생성 가능
• 한 Scope 내에서 Collection 명은 중복 불가, 다수 Scope에 동일한 Collection 명은 가능
• Scope 별로 접근 권한 부여 가능(Role Based Access Control)
• Scope 명 : 최대 251 문자, 알파벳(대소문자), 숫자(0-9), 심볼문자(-, %, _), 대소문자 구분(Case Sensitive)
• _default Scope : _default Collection이 존재하는 Scope

Scope, Collection이 주는 장점은 다음과 같습니다.

• 유사한 Document에 대한 논리적인 그룹 생성으로 Query, 클러스터 간 복제, 백업, 복구 작업이 간결
• 특정 Collection에 대한 인덱스 생성 및 관리로 인덱스 효율성 증가
• 특정한 데이터 셋(Collection)을 바로 표현할 수 있는 간결한 Query 문장
• 테이블 기반 관계형 데이터베이스 모델을 이관이 용이, 테이블을 바로 Collection에 매핑
• Bucket 내 데이터 보안 레벨이 더욱 세분화, 예전 Bucket 단위에서 Collection 단위로

참고자료

https://docs.couchbase.com/server/current/learn/data/scopes-and-collections.html

이번 블로그는 Application에서 지속적으로 변경할 수 있는 가볍고 유연한 스키마를 위한 JSON 데이터 모델에 대해서 살펴 보겠습니다.

Couchbase가 기본적으로 사용하는 JSON 데이터 모델의 장점은 다음과 같습니다.

• 기본적인 데이터 타입 제공 : 숫자, 문자열, 내장 Document, 배열 등
• 빠른 Serialization/Deserialization을 제공
• JavaScript와 완벽한 호환
• 대부분의 REST API 반환 타입으로 웹 어플리케이션 프로그래밍의 적합

JSON Document의 특징은 다음과 같습니다.

• 주로 개별 Document는 어플리케이션에서 특정 오브젝트의 단일 인스턴스를 표현
• Document는 관계형 테이블의 개별 레코드(로우, Row)에 해당
• Document 내의 Attribute는 관계형 테이블의 개별 컬럼에 해당
• JSON Document는 관계형 테이블의 레코드와 달리 유연한 스키마
• 계층적 데이터 구조를 표현할 수 있는 Nested 구조 지원

관계형 데이테 모델과 JSON Document 모델의 차이를 다음처럼 비교할 수 있습니다.

• 특정한 두 공항 간 비행 스케줄을 검색하는 경우를 예로 들면, 관계형 데이터 모델은 관련 테이블을 조인해야 하고 JSON Document 모델은 관련 정보가 1 개의 JSON Document에 모두 Embedding(특히 스케줄은 배열 형태로 저장)
• 어플리케이션의 요청에 대한 빠른 응답, 확장성 및 낮은 Latency 제공
• Document의 쉬운 복제, 다른 Document와 독립적인 높은 Atomicity, 복찹한 노드 간 상호 작업 감소로 경합 최소화 

JSON Document 모델은 유연하고 동적인 특징을 가지고 있습니다.

• JSON Document 모델의 스키마는 어플리케이션 데이터 구조의 결과
• JSON Document 모델의 스키마는 전적으로 어플리케이션에 의해 정의되고 관리
• JSON Document 구조는 "Attribute - Value" pair로 내부적으로 구성
• Couchbase는 스키마에 어떠한 제약 조건도 강제하지 않는 특징
• 동일한 오브젝트 혹은 Collection을 표현하는 Document도 스키마가 서로 상이할 수 있는 유연성

최적의 JSON Document 모델은 Access Pattern과 오브젝트 관리 방식을 고려해야 합니다.

• 데이터가 복잡하게 Embedding 하여 Document의 수가 감소하는 모델 : 동시에 조회되거나 변경되는 데이터의 그룹인 경우 적합, 단일 작업으로 읽고 쓸 수 있는 장점, 높은 Atomicity, 오브젝트 간 관련성이 적어 확장성 유리
• 서로를 참조하도록 간결한 Document로 구성하지만 Document 수가 증가하는 모델 : Access Pattern이 예측 가능한 경우 적합, Document 크기 감소, 네트워크 통신 용량 감소, Key를 통한 참조(조인)

참고자료

https://docs.couchbase.com/server/current/learn/data/document-data-model.html

Couchbase 한국 지사 설립 이후 처음으로 공개 웨비나 "카우치베이스 - 메모리 기반의 차세대 NoSQL 데이터 플랫폼 : NoSQL의 한계를 넘어 Enterprise SQL까지" 를 마련하였습니다. 아직 Couchbase에 생소한 유저뿐만 아니라 기존 유저에게도 새로운 기능을 탑재한 통합 데이터 플랫폼인 Couchbase 최신 소식을 전할 수 있는 좋은 기회가 될 것으로 생각합니다.

9월 1일 오후 2시입니다. 다음 링크를 통해 많은 분들이 등록해 주시면 감사하겠습니다.

https://talkit.tv/Event/2889

이번 블로그는 장애 대비를 위해 데이터를 백업할 수 있는 Backup 서비스를 살펴 보도록 하겠습니다.

Backup 서비스의 특성은 다음과 같습니다.

• 개별적인 Bucket 혹은 모든 Bucket에 대해 Full 백업과 Incremental 백업의 스케줄링을 지원
• 이전에 수행된 백업의 Merge 작업 스케줄링 지원
• 백업될 데이터는 서비스 단위로 선택도 가능

Backup 서비스의 아키텍처는 다음과 같습니다.

• leader-follower 아키텍처 : 클러스터 내 Backup 서비스를 운영하는 노드 중 한 개의 노드가 leader로 선출되고 이 노드가 백업 작업을 분배, 관리하고 백업 스토리지도 모든 Backup 서비스 노드에서 접근 가능한 지 확인
• leader 노드에 장애가 생기면 Rebalance가 수행될때까지 Backup 서비스가 중단되고 Rebalance 과정에서 새로운 leader 노드를 선출하고 Backup 서비스는 재개

Backup 서비스는 Plan이라는 스케줄링을 통해 자동화합니다. Plan은 다음 정보를 포함합니다.

• 백업될 서비스
• 백업을 수행할 스케줄
• 수행할 작업 종류 : Full/Incremental/Merge

Backup 서비스는 Repository라는 개념을 사용합니다.

• Repository : 백업되는 데이터를 저장할 위치
• 클러스터 내 모든 노드가 접근할 수 있는 위치
• 특정 Plan에 정의

Backup 서비스는 특정 Repository에 저장된 백업에 대한 히스토리에 대한 검사를 수행할 수 있고 Plan을 생성, 조회, 삭제할 수 있습니다. Repository에서 특정 Document도 검색할 수 있습니다.

그리고 Backup 서비스는 특정 Repository에 저장된 개별 백업, 선택된 백업으로 클러스터를 복구하거나 개별 Bucket을 복구할 수 있습니다. 일부 데이터만을 복구하기 위해 특정한 Document Key와 Value 만을 필터링할 수 있습니다.

Backup 서비스는 더 이상 필요하지 않은 Repository를 아키이빙할 수 있습니다. 아키이빙된 Repository는 접근은 가능하지만 그 Repository에 더 이상 백업을 수행할 수 없습니다.

참고자료

https://docs.couchbase.com/server/current/learn/services-and-indexes/services/backup-service.html