NoSQL은 관계형 모델 이외의 다양한 데이터베이스를 묶어 부르는 용어입니다. 보통 “Not Only SQL”로 설명하지만, 이름만으로 쿼리 언어·트랜잭션·분산 방식을 결정할 수는 없습니다. 어떤 제품은 SQL과 비슷한 언어를 제공하고 여러 데이터 모델을 함께 지원합니다.
1. RDBMS와 NoSQL을 비교할 때 피할 단정
| 질문 | 확인할 기준 |
|---|---|
| 수평 확장이 가능한가? | 제품의 분산 구조, 샤딩 키, 교차 파티션 연산 |
| 스키마가 있는가? | 저장소의 타입·검증 규칙과 애플리케이션 계약 |
| 트랜잭션이 가능한가? | 단일 항목·문서·파티션·여러 노드 중 지원 범위 |
| 최신 데이터를 읽는가? | 읽기 위치와 일관성 설정, 복제 지연 |
| 빠른가? | 조회 패턴, 인덱스, 데이터 분포와 내구성 조건 |
RDBMS는 수직 확장만 하고 NoSQL은 수평 확장만 하는 것이 아닙니다. RDBMS도 복제·샤딩과 분산 SQL 구성을 사용할 수 있습니다. NoSQL도 핫 파티션이나 교차 노드 연산 때문에 확장 효과가 제한될 수 있습니다.
ACID의 일관성은 트랜잭션이 정의된 제약을 보존한다는 의미입니다. 분산 시스템에서 최신 값을 관찰하는 의미의 일관성과 같은 말로 혼용하지 않습니다. “RDBMS는 언제나 강한 일관성, NoSQL은 언제나 최종적 일관성”이라는 표만으로 제품을 선택하면 안 됩니다.
MongoDB는 단일 문서의 원자적 갱신과 여러 문서에 걸친 트랜잭션을 지원합니다. 트랜잭션의 배포 조건과 읽기·쓰기 concern, 비용을 확인해야 합니다. DynamoDB도 지원 대상에 대해 강한 읽기를 선택할 수 있으며, 전역 보조 인덱스 등에는 제약이 있습니다. MongoDB 트랜잭션, DynamoDB 읽기 일관성
2. 네 가지 데이터 모델
| 유형 | 표현 방식 | 잘 맞는 접근 | 주의할 점 |
|---|---|---|---|
| 키-값 | 키로 값이나 자료구조에 접근 | 세션·캐시·정해진 키 조회 | 값 크기, TTL, 영속화와 키 분포 |
| 문서 | 중첩 필드를 가진 문서 | 카탈로그·프로필·콘텐츠 메타데이터 | 문서 경계, 배열 증가, 갱신·인덱스 비용 |
| 와이드 컬럼 | 행 키·파티션을 중심으로 많은 값을 관리 | 대량 쓰기·정해진 키와 범위 조회 | 파티션 크기, 키 순서, 지원 쿼리 |
| 그래프 | 정점과 관계 또는 RDF 등 | 다단계 관계 탐색 | 탐색 깊이, 높은 연결 수, 실행 비용 |
이 표는 기능의 우열이 아니라 데이터에 접근하는 방법의 차이를 보여줍니다.
키-값
Redis, DynamoDB 같은 제품을 떠올릴 수 있지만 제공 기능은 다릅니다. Redis는 문자열 외에도 여러 자료구조를 제공하고, DynamoDB는 키-값과 문서 모델을 함께 다룹니다. Memcached는 주로 휘발성 분산 캐시이므로 영속 DB와 동일하게 취급하지 않습니다.
이미지·영상 파일을 키로 찾을 수 있다는 이유만으로 대용량 원본을 모두 Redis에 넣는 것은 적절하지 않을 수 있습니다. 저장 크기 제한과 메모리 비용을 확인하고, 객체 스토리지에 파일을 두고 DB에는 위치·메타데이터를 저장하는 구성을 검토할 수 있습니다.
문서
MongoDB 같은 문서 DB는 문서마다 필드 구성이 달라도 저장할 수 있습니다. 그렇다고 스키마 설계가 필요 없는 것은 아닙니다. 필수 필드·타입·버전은 애플리케이션과 저장소의 검증 규칙으로 관리합니다. MongoDB의 스키마 검증도 사용할 수 있습니다. MongoDB 스키마 검증
같이 읽고 변경하는 값은 한 문서로 묶는 것이 유리할 수 있지만, 무한히 늘어나는 목록을 한 문서에 넣으면 크기와 갱신 경합 문제가 생깁니다. 참조와 중첩을 조회·변경 패턴에 맞춰 선택합니다.
와이드 컬럼
Cassandra, HBase와 Bigtable을 같은 계열로 소개할 수 있지만 모델은 동일하지 않습니다. Cassandra의 CQL 테이블은 컬럼과 타입을 정의하며, 파티션 키와 클러스터링 컬럼에 맞춰 조회를 설계합니다. HBase·Bigtable의 컬럼 패밀리와 동적 qualifier 개념을 그대로 모든 Cassandra 행의 스키마 설명으로 옮기면 안 됩니다.
또한 와이드 컬럼 저장소와 ClickHouse 같은 분석용 컬럼 지향 저장소는 다른 분류입니다. 이름에 컬럼이 들어간다고 모든 컬럼을 자유롭게 집계하는 OLAP 엔진이 되는 것은 아닙니다.
그래프
Neo4j 같은 속성 그래프에서는 정점·관계와 각각의 속성을 모델링합니다. RDF 기반 그래프는 다른 표현과 쿼리 언어를 사용할 수 있습니다. 친구의 친구, 경로와 공통 연결을 탐색할 때 적합할 수 있지만, 깊이 제한 없이 모든 경로를 탐색하면 결과와 계산량이 급증합니다.
3. 무결성과 스키마의 책임
관계형 DB에서는 기본 키·유일성·외래 키·체크·NOT NULL 같은 제약을 사용할 수 있습니다. 다만 SQL DB에서 모든 테이블에 기본 키 선언이 강제되는 것은 아닙니다. 기본 키가 선언되면 고유하고 NULL이 될 수 없으며, 외래 키는 DBMS가 허용하는 고유 키도 참조할 수 있습니다. 참조 컬럼의 NULL 허용 여부는 별도 제약에 따릅니다.
NoSQL에서 외래 키가 없거나 기능이 제한되어 있다면 관계를 유지하는 책임이 애플리케이션에 남을 수 있습니다. 회원 삭제 시 문서·검색 인덱스·캐시를 어떻게 정리할지, 실패하면 어디서 다시 시작할지 정해야 합니다. 유연한 스키마도 여러 버전의 데이터를 읽고 갱신하는 비용을 없애 주지는 않습니다.
BASE는 일부 분산 시스템의 설계를 설명하는 용어이며 모든 NoSQL 제품에 동일하게 적용되는 기능 명세가 아닙니다. 실제로 필요한 보장은 제품의 트랜잭션과 읽기·쓰기 설정으로 확인합니다.
4. 선택은 대표 요청에서 시작하기
- 가장 자주 읽고 변경하는 데이터를 나열합니다.
- 한 번에 원자적으로 바뀌어야 하는 범위를 정합니다.
- 키 하나에 부하가 몰리거나 문서·파티션이 계속 커질 상황을 확인합니다.
- 인덱스·복제·백업을 포함한 비용을 측정합니다.
- 중복·삭제·장애 전환·복구를 시험합니다.
RDBMS와 NoSQL을 함께 사용하는 것도 가능합니다. 이 경우 각 데이터의 기준 저장소와 다른 사본의 갱신·재구축 방법을 명확히 해야 합니다. 모델이 조회 패턴에 잘 맞는지, 필요한 보장을 감당 가능한 비용으로 제공하는지가 선택의 핵심입니다.
