Couchbase Server 는 JSON 문서를 다루는 분산 NoSQL 데이터베이스다. 메모리를 1차 저장 계층으로 쓰는 구조라 키-값 접근이 매우 빠르고, 그 위에 SQL 과 유사한 질의 언어와 인덱스 · 검색 · 분석 기능이 얹혀 있다. 캐시 계층과 문서 저장소를 하나로 합친 자리를 노린 제품으로 이해하면 방향이 맞다.
질의 언어의 공식 명칭은 현재 SQL++ 이고, 예전 이름인 N1QL 도 문서와 도구에 여전히 남아 있다. 두 이름은 같은 것을 가리킨다.
| 단위 | 설명 |
|---|---|
| 클러스터 | 여러 노드가 하나의 데이터베이스처럼 동작하는 묶음 |
| 버킷(Bucket) | 데이터를 담는 최상위 컨테이너. RDBMS 의 데이터베이스에 대응한다 |
| 스코프(Scope) | 버킷 안의 논리적 구획. 스키마에 대응한다 |
| 컬렉션(Collection) | 스코프 안의 문서 묶음. 테이블에 대응한다 |
| 도큐먼트(Document) | JSON 하나. 고유한 키를 가진다 |
버킷 → 스코프 → 컬렉션 계층은 Couchbase 7.0 에서 들어왔다. 그 이전 버전에서 옮겨 온 데이터는 _default 스코프와 _default 컬렉션에 들어간다.
Couchbase 는 노드마다 어떤 서비스를 돌릴지 정한다. 이것이 운영 복잡도의 주요 원인이자 성능 조율의 수단이다.
| 서비스 | 역할 |
|---|---|
| Data | 문서 저장과 키-값 접근. 메모리 캐시를 담당한다 |
| Index | 전역 보조 인덱스 유지 |
| Query | SQL++ 질의 실행 |
| Search | 전문 검색과 벡터 검색 |
| Analytics | 운영 데이터에 영향을 주지 않는 분석 질의 |
| Eventing | 문서 변경에 반응하는 서버 측 함수 |
같은 노드에 여러 서비스를 얹을 수 있지만, 규모가 커지면 Data 와 Index · Query 를 다른 노드로 분리하는 것이 정석이다. 질의 부하가 데이터 노드의 메모리를 잠식하는 것을 막기 위해서다.
메모리 우선 구조. 활성 데이터셋이 메모리에 올라가 있을 때 성능이 나온다. 반대로 메모리에 담기지 않는 크기를 다루면 디스크 접근이 늘어 이점이 사라진다. 사이징의 핵심 질문은 "작업 집합이 메모리에 들어가는가" 다.
자동 복제와 페일오버. 버킷마다 복제본 수를 정하면 노드 장애 시 복제본이 활성으로 승격된다. 클러스터 사이 복제는 XDCR 로 한다.
수평 확장. 노드를 추가하고 리밸런스를 돌리면 vBucket 이 재분배된다. 리밸런스 중에도 서비스는 계속된다.
SQL++ 질의. JSON 문서를 SQL 문법으로 조회한다. 조인과 집계가 되지만 RDBMS 의 SQL 과 완전히 같지는 않아서 별도 학습이 필요하다.
트랜잭션. 다중 문서 ACID 트랜잭션을 지원한다. "NoSQL 이므로 트랜잭션이 없다" 는 오래된 설명이며, 현재는 SDK 와 SQL++ 양쪽에서 쓸 수 있다. 다만 트랜잭션을 많이 쓰면 성능 이점이 줄어든다.
| 항목 | 내용 |
|---|---|
| 운영 복잡도 | 서비스 분리, 인덱스 설계, 리밸런스 계획을 이해해야 한다 |
| 메모리 비용 | 성능이 메모리에 묶여 있어 대용량 보관에는 비싸다 |
| 일관성 모델 | 기본 읽기는 복제 지연이 있는 모델이다. 강한 일관성이 필요하면 질의에 일관성 수준을 지정해야 하고 대기 시간이 늘어난다 |
| 에디션 차이 | XDCR 고급 기능, 일부 보안·분석 기능은 Enterprise Edition 전용이다 |
| 생태계 | MongoDB · Redis 에 비해 ORM 과 서드파티 도구가 적다 |
어울리는 곳은 실시간 세션 관리, 전자상거래 장바구니, 모바일 앱 백엔드, IoT 수집처럼 키로 찾는 접근이 대부분이고 지연 시간이 중요한 워크로드 다. 캐시와 저장소를 따로 두던 구성을 하나로 합치는 목적에도 맞는다.
어울리지 않는 곳은 대규모 아카이빙과 배치 분석이다. 메모리 비용이 그대로 저장 비용이 되므로 객체 스토리지 기반 분석 플랫폼이 낫다. 복잡한 다중 테이블 조인과 엄격한 제약 조건이 중심이면 관계형 데이터베이스가 맞다.