1. NoSQL 개념과 정의

1.1. 정의

• 대용량 웹 서비스를 위하여 만들어진 데이터 저장소
• 관계형 데이터 모델을 지양하며 대량의 분산된 데이터를 저장하고 조회하는 데 특화된 저장소
• 스키마 없이 사용 가능하거나 느슨한 스키마를 제공하는 저장소

1.2. 탄생 배경

일반적으로 관계형 데이터베이스(RDBMS)는 저장된 데이터의 양이 많아질수록 읽기/쓰기 성능의 저하가 일어난다. 특히 쓰기 성능의 저하가 심한데, 이는 대부분의 관계형 데이터베이스가 채택하고 있는 인덱스 처리 방법인 B트리의 한계에서 기인한다. 또한 관계형 데이터베이스는 중앙 집중식 데이터 관리 패턴에 해당하기 때문에 단일 하드웨어의 성능에 따라 전체 시스템의 성능이 결정된다.

NoSQL은 대량의 데이터를 빠르게 처리하기 위해서 메모리에 임시 저장하고 응답하는 등의 방법을 사용한다. 또한 동적인 스케일 아웃을 지원하기도 하며, 가용성을 위하여 데이터 복제 등의 방법으로 관계형 데이터베이스가 제공하지 못하는 성능과 특징을 제공한다. 스키마 없이 데이터를 저장하고 조회할 수 있으며 실시간으로 시스템의 확장과 축소를 지원하기도 한다. 또한 시스템 정지 없이 저장소 소프트웨어의 업그레이드를 수행할 수도 있다.

2. CAP 정리

CAP 정리란 컴퓨터 과학 분야에서 분산 컴퓨터 시스템을 설명하는 데 사용되는 이론이다.

2.1. 일관성(Consistency)

일관성은 동시성 또는 동일성이라고도 하며 ‘다중 클라이언트에서 같은 시간에 조회하는 데이터는 항상 동일한 데이터임을 보증하는 것'을 의미한다.

일관성은 관계형 데이터베이스가 지원하는 가장 기본적인 기능이다. 하지만 NoSQL에서는 빠른 분산 처리를 위하여 일관성을 희생하기도 한다.

많은 NoSQL 솔루션은 읽기와 쓰기의 성능 향상을 위해 데이터를 메모리에 임시로 기록한 다음 클라이언트에 응답하고 백그라운드 스레드(혹은 프로세스)로 해당 데이터를 디스크에 기록한다. 이런 처리 방식의 장점은 빠른 응답 속도에 있으며, 데이터 변경에 따른 수정 비용이 적게 든다는 장점이 있다. 반면 정전과 같은 하드웨어 장애 발생 시에는 데이터 유실이 발생할 수 있다.

카산드라와 HBase에서는 이런 데이터의 유실을 방지하기 위하여 메모리에 저장하기 전에 커밋로그 및 WAL(Write Ahead Log) 파일에 먼저 정보를 기록하여 데이터의 유실을 방지하는데, 레디스도 이와 유사한 기능인 AOP(Append Only File)를 사용한다.

2.2. 가용성(Availability)

가용성이란 ‘모든 클라이언트의 읽기와 쓰기 요청에 대하여 항상 응답이 가능해야 함을 보증하는 것'이며 내고장성이라고도 한다. 내고장성을 가진 NoSQL은 클러스터 내에서 몇 개의 노드가 망가지더라도 정상적인 서비스가 가능하다.

2.3. 네트워크 분할 허용성

분할 허용성(Partition tolerance)이란 ‘지역적으로 분할된 네트워크 환경에서 동작하는 시스템에서 두 지역 간의 네트워크가 단절되거나 네트워크 데이터의 유실이 일어나더라도 각 지역 내의 시스템은 정상적으로 동작해야 함’을 의미한다.

3. NoSQL 분류와 저장구조

NoSQL은 데이터의 저장 방식에 따라 분류되기도 한다.

3.1. 키-값 모델 NoSQL

키-값 모델 NoSQL은 가장 기본적인 형태의 NoSQL이며, 키 하나로 데이터 하나를 저장하고 조회할 수 있는 단일 키-값 구조를 가진다.

3.1.1. 공통 특징

키-값 모델 NoSQL에 저장 가능한 데이터의 종류는 각 NoSQL별로 상이한데, 대부분의 키-값 모델 NoSQL은 단순한 저장구조로 인하여 복잡한 조회 연산을 지원하지 않는다. 키-값 모델 NoSQL로는 레디스, 리악(Riak), 볼드모트 등이 있다.

3.1.2. 데이터 저장 방법

단일 키에 단일 데이터를 저장하는 간단한 구조로 인하여 주로 단순한 정보의 빠른 저장과 조회를 제공한다.

3.1.3. 적절한 사용처

키-값 모델 NoSQL은 사용자의 프로필 정보, 웹 서버의 클러스트를 위한 세션 정보, 장바구니 정보, URL 단축 정보 저장 등이 해당된다. 위의 예제들은 모두 단일 연산에 의하여 처리를 완료하거나 취소를 할 수 있기 때문이다.

3.2. 문서 모델 NoSQL

문서 모델 NoSQL 저장소는 키-값 모델을 개념적으로 확장한 구조다. 하나의 키에 하나의 구조화된 문서를 저장하고 조회한다.

3.2.1. 공통 특징

대부분의 문서 모델 NoSQL은 B트리 인덱스를 사용하여 2차 인덱스를 생성한다. B트리는 크기가 커지면 커질수록 새로운 데이터를 입력하거나 삭제할 때 성능이 떨어지게 된다. 이런 이유로 B트리를 사용하는 모델 NoSQL은 읽기와 쓰기의 비율이 7:3 이상일 때 가장 좋은 성능을 보인다. 문서 모델 NoSQL에는 MongoDB, 카우치베이스, 테라스토어, 레이븐DB 등이 있다.

3.2.2. 데이터 저장 방법

관계형 데이터베이스는 아래와 같은 데이터를 저장하기 위해서 반드시 skills 컬럼을 정의하고 null 값을 넣어야 하지만, 문서 모델 NoSQL은 항상 고정된 필드를 가진 구조의 문서를 저장할 필요가 없다.

3.2.3. 적절한 사용처

문서 모델 NoSQL은 B트리의 특성으로 인하여 한 번 작성되면 자주 변하지 않는 정보를 저장하고 조회하는 데 적합하다. 예를 들어 중앙 집중식 로그 저장, 타임라인 저장, 통계 정보 저장 등이 이에 해당한다. 2차 인덱스는 조회 기능의 편의성을 제공하기도 하지만, 쓰기 성능을 저하시키는 양날의 검과 같은 기능이다.

3.3. 컬럼 모델 NoSQL

컬럼 모델 NoSQL은 하나의 키에 여러 개의 컬럼 이름과 컬럼 값의 쌍으로 이루어진 데이터를 저장하고 조회한다. 단일 키에 의한 단일 컬럼 및 범위 조회도 가능하다. 모든 컬럼은 항상 타임스탬프값과 함께 저장된다.

3.3.1. 공통 특징

대부분의 컬럼 모델 NoSQL은 구글 빅테이블의 영향을 받아 개발됐다. 이러한 이유로 로우키, 컬럼키, 컬럼 패밀리키 같은 빅테이블 개념이 공통적으로 사용된다. 컬럼 모델 NoSQL에서 컬럼 하나를 조회할 때는 행을 구분하는 로우키와 열을 구분하는 컬럼키를 사용한다. 마치 스프레드시트에서 X축, Y축에 따라 셀을 조회하는 방법과 동일하다. 컬럼 모델 NoSQL로는 HBase, 카산드라, 하이퍼 테이블 등이 있다.

3.3.2. 데이터 저장 방법

로우키의 정렬은 바이트 단위의 사전식 정렬을 따른다. 또한 컬럼 패밀리에 포함된 컬럼의 정렬도 로우키의 정렬 순서와 동일한 기준을 따라서 정렬된다.

3.3.3. 적절한 사용처

대부분의 컬럼 모델 NoSQL은 쓰기와 읽기 중에서 쓰기에 더 특화되어 있다. 쓰기 연산은 데이터를 먼저 커밋로그와 메모리에 저장한 후 응답하기 때문에 매우 빠른 응답 속도를 제공한다. 이와 같은 이유로 읽기 연산 대비 쓰기 연산이 많은 서비스나 빠른 시간 안에 대량의 데이터를 입력하고 조회하는 서비스를 구현할 때는 가장 좋은 성능을 나타낸다. 예를 들어 채팅 내용 저장, 메일 저장소, 알림 내용 저장, 실시간 분석을 위한 데이터 저장소 등의 서비스 구현에 적합하다.

3.4. 그래프 모델 NoSQL

그래프 모델 NoSQL은 노드와 관계(또는 버텍스와 엣지라고 한다)를 사용하여 데이터를 저장하고 조회하는데, 관계는 속성이라는 부가 정보를 가진다. 관계형 데이터베이스는 엔티티와 관계를 레코드로 표현하는데, 그래프 모델 NoSQL은 노드와 관계로 표현한다.

3.4.1. 공통 특징

그래프 모델 NoSQL은 노드와 노드 간의 관계를 저장하며 노드가 하나일 때는 관계를 지정할 수 없다. 노드의 조회를 위해서 관계를 조회 조건으로 사용한다. 관계는 방향성을 가지기도 하는데, 이 방향성에 의하여 어러 단계의 조회가 가능하다. 이를 순회라고 한다. 그래프 모델 NoSQL은 많이 알려지지 않았기 때문에 서비스 도입 사례가 적으며, 그래프 자체의 복잡성으로 인하여 도입을 위한 기술적 장벽이 있다.

3.4.2. 데이터 저장 방법

그래프 모델 NoSQL을 관계형 데이터베이스의 구성요소와 대응시키면 엔티티 테이블은 노드, 관계 테이블은 노드 간의 관계가 된다. 그래프 데이터베이스의 장점은 관계를 통해 부가 정보를 조회할 수 있는 데 있다.

3.4.3. 적절한 사용처

그래프 모델 NoSQL은 친구 추천과 같은 연관 검색을 위한 정보를 저장하고 조회하는데 적합하다. 기존 관계형 데이터베이스에서 구현하기 까다로운 부분이 그래프 모델 NoSQL에서는 기본으로 제공되기 때문이다. 추천 시스템,다중 관계를 가진 엔티티를 저장학 조회하는 데 알맞다.

4. 언제 NoSQL을 사용해야 하는가?

대량의 단순 정보를 빠르게 저장하고 조회할 때, 관계형 데이터베이스가 처리하지 못하는 대량의 데이터를 입력할 때, 스키마가 고정되지 않은 데이터를 저장하고 조회할 때 등이 NoSQL을 사용할 때이다.

NoSQL 도입을 확정했다며, 다음으로는 어떤 NoSQL을 사용할지 결정해야 한다. 관계형 데이터베이스에서 NoSQL로 데이터 저장소를 변경할 때, 가장 먼저 고려해야 할 사항은 일관성 모델이다. 구현된 서비스에 강한 일관성 모델이 필요한지, 느슨한 일관성 모델을 사용해도 큰 문제가 되지 않는지에 대한 판단이 우선시되어야 한다.

만약 주 서비스에 NoSQL을 도입하는 것이 꺼려진다면 부분적인 도입으로부터 출발하는 것도 좋은 방법이다. 중요도가 낮거나 장애시 영향도가 낮은 서비스를 대상으로 먼저 적용해보자.