카우치디비
카우치디비(Couch DB)는 Cluster Of Unreliable Commodity Hardware의 약어로 2005년에 개발이 시작되고, 2008년초에 아파치 인큐베이팅 프로젝트에 등록된 문서 기반 데이터베이스이다. 이 프로젝트를 이끌고 있는 사람은 Damien Katz씨로 로터스에서 근무했고 현재는 IBM에서 일하고 있다. 카우치디비는 아파치 프로젝트 중에서 유일하게 얼랭(Erlang)을 언어로 사용하고 있다. 얼랭으로 구현되어 있지만 사용자들은 얼랭을 알 필요가 없다.[1]
목차
개요
=== 얼랭으로 구현된 문서 기반 분산 데이터베이스, 카우치디비(CouchDB) 카우치디비(CouchDB)는 Cluster Of Unreliable Commodity Hardware의 약어로, 2008년 2월에 아파치 인큐베이팅 프로젝트에 편입된 문서 기반 데이터베이스이다. 현재 아파치 프로젝트 중에서는 유일하게 얼랭을 언어로 사용한다. 카우치디비(CouchDB)가 얼랭으로 구현되긴 했지만 다른 [[데이터베이스]를 사용할 때 C/C++를 쓰는게 아니라 SQL을 쓰는 것처럼, 카우치디비(CouchDB)를 사용하기 위해 얼랭을 알아야 할 필요는 없다. 하지만, 관계형 데이터베이스가 아닌 문서 기반 데이터베이스이기 때문에, SQL 대신 JSON과 자바스크립트를 사용한다는 것이 대단히 특이한 점이라 할 수 있다. JSON은 데이터 표현에 사용되고, 자바스크립트는 쿼리에 사용된다. 대부분의 플랫폼과 언어들이 [[HTTP]를 지원하고, JSON 파싱도 어려운 일이 아니므로 어떤 환경에서도 쉽게 카우치디비(CouchDB)와 인터페이스 할 수 있다. 이런 면에서는 예전에 루비 세미나에서 deepblue님이 발표하신 슬러거와 비슷한 점이 있다. 그러나 RSET 스타일의 JSON 프로토콜을 사용한다는 것 이외에도 복제와 MapReduce 프로그래밍 모델이 자연스럽게 지원된다는 것이 가장 큰 특징이다. 이것이 데이터베이스에서 지원된다면 또 다른 가능성이 열리는 셈이다. 양방향 복제도 지원되고, 오프라인 모드로 사용하다가 나중에 동기화 하는 것 역시 가능하다.[2]
기술 개요
- 문서 저장소
문서는 카우치디비(CouchDB)에서 가장 기본적인 데이터 단위이며, 다수의 필드와 첨부 파일로 구성된다. 문서에는 데이터베이스 시스템이 관리하는데 필요한 메타데이터도 포함된다. 각 문서 필드는 유일한 이름을 가지고 있고, 텍스트, 숫자, 불린, 리스트 등 다양한 타입의 값을 사용할 수 있으며, 텍스트 크기나 필드 수에는 아무런 제약이 없다. CVS나 서브버전을 쓴다면 익숙하겠지만, 카우치디비(CouchDB)의 업데이트 모델은 낙관적인 모델이라 잠금을 사용하지 않는다. 만약 여러 명의 사용자가 동시에 같은 문서를 편집하는 상황이 발생하면, 나중에 저장하는 사람은 충돌이 발생했음을 알게 된다. 나중에 넣는 최신 버전을 기반으로 다시 써서 넣도록 되어있다.
- 모든 문서는 데이터와 연관된 인덱스 업데이트는 동기적으로 디스크에 쓴다.
- 이어서 업데이트 된 데이터베이스 헤더를 쓰고, 각 청크들이 모여서 4K가 채워지면 디스크에 동기적으로 쓴다.
- 뷰
카우치디비(CouchDB)는 비정형 데이터를 다루기 위해 자바스크립트 함수를 이용해 데이터 가공을 처리한다. 이 자바스크립트 함수를 뷰라고 하는데 MapReduce 모델로 되어있다. 뷰는 카우치디비(CouchDB) 문서를 인수로 받아 계산을 수행하면서 키-값 쌍을 추가한다. Reduce 함수가 정의되어 있다면 Map 함수에서 발생시킨 키-값 쌍을 받아서 키를 기준으로 데이터를 가공한다. 조회 결과는 Map 함수에서 넘겨준 키를 기준으로 정렬된다. 키 값이 null이면 문서 ID를 기준으로 정렬한다.
- 보안과 유효성 검증 = 카우치디비(CouchDB)는 누가 문서를 읽고 수정할 수 있는지 제한할 수 있도록, 간단하면서도 확장 가능한 보안 모델을 가지고 있다.
- 관리자 접근 = 관리자 계정의 경우 다른 관리자 계정을 만들거나 설계 문서를 수정할 수 있다.
- 리더 접근 = 카우치디비(CouchDB) 문서에 리더(Reader) 목록을 저장한다. 따로 정의된 게 없으면 누구나 읽을 수 있지만, 목록이 정의되어 있는 경우에는 지정된 사용자만 읽기가 가능하다. 뷰에서 접근할 때도 이 접근 제한이 동일하게 적용된다. 접근 권한이 없으면 뷰 조회 결과에서 빠지도록 되어 있다.
- 업데이트 접근 = 디스크에 문서를 쓰는 시점에 자바스크립트 함수를 이용하여 유혀성 검증이 이뤄진다. 유효성 검증을 통과하면 그대로 업데이트를 진행할 수 있는 반면, 그렇지 않은 경우에는 작업이 중단되고 클리이언트는 오류 응답을 받는다. 자바스크립트 함수의 매개변수로 사용자 계정 정보와 업데이트 한 문서가 같이 넘어오므로, 이 값을 이용하여 권한을 결정한다. 가령, 최초 작성자만 문서를 수정할 수 있도록 하고 싶다면 간단히 문서의 author 필드와 현재 사용자 계정을 비교하도록 코드를 작성하면 된다.[3]
주요 특징
- Document Storage = 문자열로 이뤄진 JSON과 같은 형태의 Document를 저장한다.
- ACID Semantics = 동시성 제어가 가능하며, 많은 사용자가 읽어나, 쓸 때 충돌없이 동작이 가능하다.
- Map/Reduce Views and Indexes = 자바스크립트를 이용해 Map/reduce작업을 진행하여 값을 구할 수 있으며, 인덱스와 뷰 등을 생성하여 관리할 수 있다.
- Distributed Architecture with Replication = 양방향의 데이터 복제 허용하여, 복제된 DB에서 변경이 일어나더라도 다른 복제본과 데이터를 서로 동기화한다.
- REST API = URI를 기준으로 POST, GET, PUT, DELETE를 이용하여 CRUD 처리가 가능하다.
- Eventual Consistency = 분산형 컴퓨팅에서 사용되는 동시성 일관성 모델인 Eventual Consistency 보장
- Built for Offline = 스마트폰과 같은 기기에도 데이터 복제가 허용되며, 온라인 상황에서 데이터 동기화 실시[4]
다른 데이터베이스(DB)와의 차이점
카우치디비(CouchDB) 와 관계형 데이터베이스의 차이점
몽고DB와 카우치DB와 같은 문서형 저장소는 데이터를 테이블에 저장하지 않고 문서 형식으로 저장하여 모든 연관된 정보들을 세분화하여 분리하지 않고 JSON 형식으로 한 문서 안에 저장을 시킨다. 대표적인 예를 들면 HTML 형식으로 이루어진 웹 문서를 생각하면 된다. 이에 반해서 관계형 데이터베이스의 경우에는 정보들을 분류 가능한 최소 단위까지 세분화하여 세분화 된 정보들 간의 관계를 설정함으로써 데이터를 구조화 시킨다. 문서형 저장소는 데이터들 간의 요소들의 관계가 비교적 느슨하며, 새로운 데이터를 추가하기 위해서 모든 문서에 불필요한 공간을 생성할 필요가 없다. 이렇게 스카마 변경에 따른 어려움이 없다는 것이 카우치디비(CouchDB)와 같은 NoSQL의 큰 장점이다.[5]
카우치디비(CouchDB) 와 몽고DB의 차이점
같은 NoSQL이면서 문서지향 데이터베이스인 몽고DB와의 차이점에 대해서 말하자면 우선 몽고DB의 경우에는 커스텀 바이너리 프로토콜(Custom Binary Protocol)을 사용하기 때문에 몽고DB를 사용하기 위해서는 별도의 드라이버(Driver)가 필요한 반면에 카우치디비(CouchDB)의 경우에는 HTTP/REST 프로토콜을 사용함으로 별도의 드라이버가 필요없고 인터넷에 연결이 되어 있으면 HTTP를 이용하여 카우치디비(CouchDB)를 사용할 수 있다. 카우치디비(CouchDB)의 사상은 간단하다. 모든 정보를 문서형태로 저장한다. 이러한 문서들을 저장하는데 초점을 맞춘다. 이에 반해서 몽고DB의 경우에는 문서 형태로 저장하는 목적이외에 문서 저장소를 관리하는 계층을 두어서 저장소에 대한 세부적인 관리를 실시한다. 몽고DB에서 쿼리(Query)를 사용하여 문서를 빠르게 검색할 수 있다. 이러한 쿼리는 관계형 데이터베이스와 유사하여 관계형 데이터베이스 사용자들이 몽고DB를 손쉽게 사용할 수 있도록 유도하는 장점중에 하나다. 하지만 카우치디비(CouchDB)는 쿼리를 뷰에 대해서만 할 수 있으며, 이 뷰는 기본적으로 Map-reduce 함수를 기반으로 작동한다. Map-reduce는 분산 환경을 위해서 탄생하였지만 쿼리 속도가 느리다는 태생적 한계점을 가지고 있다. 카우치디비(CouchDB)를 적용하기 쉬운 분야로는 CRM, CMS와 같은 데이터를 누적하는 시스템 및 데이터의 변화가 별로 없는 시스템이며, 몽고DB는 동적인 질의가 필요한 시스템이나 빠른 조회를 위해서 인덱스 사용이 필요한 시스템에 사용하는 것이 적절하다.[6]
단점
- 메모리 내 DBMS보다 느리다.
- 적절한 업데이트를 수행하려면 서버 쪽 논리 (update handlers)이 필요하다.
- 디스크 대 속도의 거래 : 데이터베이스는 다른 DBMS에 비해 엄청나게 커질 수 있다.
- "유일한" 최종 일관성
- 대규모 데이터 세트의 임시보기는 매우 느리다.
- 대규모 데이터베이스 may fail 복제.
- 지도 / 축소 패러다임을 위해서는 재고가 필요하다.[7]
전망
밥 위더홀드 카우치베이스 최고경영자(CEO)는 지난해 300억달러로 추산된 세계 DB 시장에서 관계형 DB가 95%를 차지했지만 15년 뒤에는 NoSQL DB가 과반으로 늘어날 것이라고 전망했다. 한국에서도 소셜네트워크, 모바일, 이커머스 등 성장세가 빠른 시장에 NoSQL 도입이 늘 것이라고 전망했다.[8] 하지만 국내시장에서는 현재 관계형 데이터베이스(DB)보다 비정형데이터 저장에 특화된 NoSQL 기술에 대한 국내 시장의 관심이 시들해졌다. 빅데이터 플랫폼의 요소기술로 주목됐지만 오픈소스 진영과 글로벌 상용 소프트웨어(SW)업체마다 제각각 대응 기술을 내놓으면서 범용 솔루션을 원하는 사용자들을 끌어안지 못하는 상황이다. NoSQL은 '키-값' 형태의 저장구조를 취해 등장 초기부터 관계형 DB처럼 SQL 방식의 조회가 불가능하다는 특징을 그린 이름을 얻었다. 관계형 DB 이외 수단으로 저장하는 DB 기술을 통칭하지만, 공통점보다 차이점이 크다. NoSQL은 관계형 DB만으론 어려웠던 비정형데이터 저장을 보완하는 빅데이터 플랫폼의 구성요소로 주목됐다. 불과 3년 전만 해도 오픈소스 관계형 DB의 맹주 MySQL의 미래를 좌우할 중대변수 가운데 하나로 꼽혔고, 최근 1~2년간 신제품 등장과 업그레이드도 경쟁적으로 이뤄졌다. 하지만 정작 시장 반응은 뜨뜻미지근했다.[9]
각주
- ↑ 류프리 〈카우치DB(Couch DB)〉 , 《네이버블로그》 , 2017-08-12
- ↑ yoontaesub 〈정보수집〉 , 《yoontaesub.egloos.com》 , 2010-10-09
- ↑ 양봉열 〈데이터기술자료〉 , 《kdata 한국데이터산업진흥원》 ,
- ↑ 바라매 〈CouchDB〉 , 《네이버블로그》 , 2015-06-25
- ↑ 류프리 〈카우치DB(Couch DB)〉 , 《네이버블로그》 , 2017-08-12
- ↑ 류프리 〈카우치DB(Couch DB)〉 , 《네이버블로그》 , 2017-08-12
- ↑ 코드로그 〈nosql-CouchDB의 단점〉 , 《codeday》 , 2019-05-12
- ↑ 임민철 기자 〈카우치베이스-N2M, 국내 NoSQL시장 맞손〉 , 《한국공개소프트웨어협회》 , 2013-03-13
- ↑ 지디넷 코리아 〈NoSQL,도입사례 고픈 빅데이터 유망주〉 , 《뉴스줌》 , 2013-01-21
같이 보기