NoSQL

하나로 묶기 어려운 데이터베이스들

간단한 키로 값을 찾는 저장소와 관계를 따라 탐색하는 그래프 데이터베이스는 사용 방법이 크게 다르다. 둘 다 NoSQL로 분류될 수 있지만 한쪽의 특징을 다른 쪽에도 그대로 적용할 수는 없다.

SQL을 쓰지 않는다는 이름만으로 범위를 설명하기도 어렵다. 일부 제품은 SQL과 유사한 조회 언어를 제공한다. 중요한 것은 언어의 이름보다 어떤 구조로 데이터를 표현하고 어떤 연산을 효율적으로 처리하는지다.

문서형 모델은 관련된 속성이나 하위 구조를 한 문서 안에 담을 수 있다. 함께 읽는 자료를 묶으면 조회가 단순해질 수 있지만 같은 내용을 여러 문서에 반복하면 변경을 일관되게 반영할 방법도 필요하다.

키-값 모델은 식별자로 바로 찾는 작업에 알맞을 수 있고 그래프 모델은 연결 관계를 탐색하는 작업을 중심으로 설계된다. 같은 서비스에서도 데이터의 성격에 따라 여러 저장 방식을 함께 이용할 수 있다.

문서마다 필드가 달라도 되는 저장소라 하더라도 프로그램은 각 필드의 뜻과 자료형을 알아야 한다. 구조의 검증을 데이터베이스에 둘지 프로그램에 둘지, 이전 형태의 문서를 어떻게 읽을지 결정해야 한다.

스키마가 유연하다는 말이 설계가 필요 없다는 뜻은 아니다. 데이터가 커진 뒤 구조를 바꾸거나 여러 형태의 기록을 함께 처리하는 비용까지 살펴야 한다.

NoSQL이면 언제나 더 빠르거나 모든 작업을 쉽게 분산할 수 있다고 단정할 수 없다. 데이터 분할 방식과 조회 패턴, 장애 시의 동작에 따라 결과가 달라진다. 관계형 시스템도 분산 구성을 지원할 수 있다.

트랜잭션과 읽기 일관성의 지원 범위 역시 제품과 설정에 따라 다르다. 하나의 항목에 대한 보장과 여러 항목을 함께 바꾸는 보장을 구분해야 한다. 모델 이름만으로 필요한 무결성이 충족된다고 판단해서는 안 된다.