Dev Wiki

부록B NoSQL 이해하기

20 min read

한 줄 정의

NoSQL은 관계형 모델과 강한 일관성의 일부를 내려놓는 대신, 대용량 분산 처리·고속 읽기 쓰기·유연한 스키마 같은 특정 요구사항에 맞춘 저장·조회 기법을 제공하는 데이터베이스입니다.

쉽게 말하면

RDBMS가 잘 정리된 문서 보관소 라면 NoSQL은 용도별 특수 창고 입니다.

문서 보관소는 정해진 양식(스키마)대로만 서류를 받고, 서류끼리 번호로 상호 참조(조인)하며, 공간이 부족하면 건물을 더 크게 증축(수직 확장)합니다. 반면 특수 창고는 물건마다 맞는 방식으로 보관합니다. 번호표만 보고 꺼내는 사물함(키-값), 관련 서류를 통째로 한 봉투에 넣는 방식(문서), 컨테이너를 옆으로 계속 이어 붙이는 물류 창고(칼럼 패밀리), 누가 누구와 연결되어 있는지 그린 인맥 지도(그래프)입니다.

창고 동은 원하는 만큼 늘릴 수 있지만(수평 확장) 물건이 여러 동에 흩어져 있으니 방금 넣은 물건이 모든 동에서 즉시 보인다고 보장하기는 어렵습니다(궁극적 일관성). 그리고 사무실 서류 몇 장을 보관하려고 물류 창고를 계약하면 관리 부담만 늘어납니다. 이 장의 도입 시 고려 사항은 전부 “창고를 빌리기 전에 무엇을 얼마나 어떻게 꺼낼지부터 정하라”는 말입니다.

왜 중요한가?

데이터에 대한 요구사항이 다양해졌습니다. 수천만 회원 간의 연결 관계를 분석해 친구를 추천하거나, 대량의 데이터를 실시간으로 수집해 통계를 뽑거나, 테라바이트에서 페타바이트 이상의 데이터를 다뤄야 하는 경우입니다.

RDBMS로도 처리할 수는 있지만 더 알맞은 기술이 있습니다. 회원 간 연결 관계는 그래프 DB가 분석에 유리하고, 대량 데이터 저장과 통계에는 수평 확장을 지원하는 DB가 필요합니다.

반대 방향의 위험도 같은 크기입니다. 데이터 저장소를 잘못 고르면 서비스에 심각한 타격을 주므로, 어떤 NoSQL이 무엇에 강하고 무엇을 포기하는지 알아야 “쓸 이유가 있는지”와 “쓰지 말아야 할 이유가 있는지”를 둘 다 판단할 수 있습니다.

핵심 내용

NoSQL이란

특정한 요구사항에 맞춰 데이터를 저장하고 조회하기 위한 기법을 제공하는 데이터베이스입니다. 전통적인 관계형 DB보다 덜 제한적인 일관성 모델을 쓰며, 디자인 단순화·수평 확장성·세세한 통제를 목표로 합니다.

Non-SQL에서 Not Only SQL로

초기 NoSQL은 SQL을 쓰지 않고 관계형 DB를 대체하려는 성격이 강해 Non-SQL로 이해됐습니다. 이후 NoSQL과 SQL을 함께 쓰는 방식으로 발전했고 NoSQL 기술도 SQL과 유사한 언어를 지원하기 시작하면서, 지금은 주로 Not Only SQL의 의미로 씁니다.

NoSQL을 쓰는 주된 이유는 네 가지입니다.

  • 대용량 데이터나 분산 처리
  • 고속의 읽기와 쓰기 성능
  • 특정한 요구사항에 맞는 데이터 설계
  • 비정형 데이터 처리 또는 유연한 스키마
수평 확장으로 용량을 늘린다

RDBMS가 수직 확장으로 용량을 늘리는 것과 달리 Cassandra나 HBase 같은 NoSQL은 노드를 추가하는 수평 확장으로 저장 용량을 늘립니다. NoSQL도 수직 확장으로 성능을 높일 수 있지만, 수평 확장의 진짜 목적은 단일 장비로는 저장할 수 없는 수준의 데이터 를 다루는 것입니다. Discord는 2023년 기준 수 조 개의 메시지를 저장하기 위해 70개 이상의 ScyllaDB 노드를 운영합니다.

RDBMS도 샤딩으로 수평 확장할 수는 있지만 NoSQL 클러스터와는 성격이 다릅니다.

RDBMS 샤딩NoSQL 클러스터
개념적 단위서로 다른 DB 10개하나의 DB
노드 하나 장애 시그 DB에 속한 데이터를 사용할 수 없음전체 클러스터가 정상 동작
성능을 얻기 위해 내려놓는 것

분산 처리와 높은 성능을 위해 NoSQL은 RDBMS가 제공하는 ACID 요건 중 일부를 지원하지 않습니다. 예를 들어 다중 네트워크의 클러스터에서 네트워크가 단절되면 일관성을 보장하지 않는 대신 DB를 계속 쓸 수 있게 합니다. 그 외에도 메모리 사용을 높이고, 빠른 읽기·쓰기에 맞는 데이터 구조를 쓰고, 인덱스 생성을 최소화하고, 데이터를 분산 저장해 병렬로 처리하는 식으로 성능을 얻습니다.

데이터 모델도 관계형 모델이 아니라 용도에 맞는 모델을 씁니다. DynamoDB는 키-값으로, MongoDB는 BSON(바이너리 JSON)으로 저장하며, 이런 모델 특성 때문에 다수의 NoSQL은 조인을 지원하지 않습니다. 스키마도 고정되어 있지 않거나 유연해서 신규 속성 추가 같은 구조 변화에 대처하기 쉽습니다.

NoSQL 종류

일반적으로 네 가지 유형으로 나눕니다.

유형저장 방식대표주요 용도
키-값 DB자바의 Map처럼 키에 값을 매핑. 모든 데이터를 값으로 사용 가능DynamoDB, Redis세션 관리(인증 토큰), 캐시, 설정 관리
문서 DBJSON과 유사한 문서 단위로 저장. 스키마 고정 없음MongoDB컨텐츠 관리, 제품 카탈로그(다양한 메타데이터)
칼럼 패밀리 DB키-값 DB의 확장. 각 행이 여러 칼럼을 갖고 칼럼들을 그룹으로 묶어 관리Cassandra, HBase채팅 메시지·IoT 데이터 같은 대규모 데이터 저장과 조회
그래프 DB노드와 엣지로 관계를 표현. 노드와 엣지가 프로퍼티를 가짐Neo4j소셜 네트워크, 친구·상품 추천, 관계 패턴 기반 부정 탐지
키-값 DB

구조가 단순해서 읽기와 쓰기가 빠릅니다. 레디스는 단순 키-값 외에도 다양한 형태의 값을 지원하는데, 정렬된 집합으로 순위표를 쉽게 구현할 수 있고 큐 기능이 있어 메시징 시스템으로도 활용할 수 있습니다.

문서 DB

JSON 형태면 되므로 RDBMS 테이블과 달리 복잡하고 중첩된 모델을 쉽게 표현합니다. 새 속성이 필요하면 추가하면 되고 중첩 구조나 배열도 쓸 수 있습니다. 가장 큰 장점은 애플리케이션의 데이터 모델과 DB의 데이터 모델이 거의 일치한다 는 점입니다. RDBMS에서는 개념적으로 하나인 모델을 저장하려고 여러 테이블을 써야 하는 경우가 많습니다.

칼럼 패밀리 DB

대량 데이터를 저장할 수 있는 수평 확장이 용이한 구조입니다.

칼럼 기반 DB와는 다릅니다

칼럼 기반(column oriented) DB 또는 칼럼형(columnar) DB는 칼럼 패밀리 DB와 다른 것입니다. RDBMS 테이블이 행 단위로 저장하는 것과 달리 칼럼 단위로 저장하며, OLAP 같은 데이터 분석 목적으로 주로 씁니다. Clickhouse, MariaDB의 ColumnStore가 여기에 속합니다.

그래프 DB

이름 그대로 데이터를 그래프 형태로 관리합니다. 노드 데이터와 노드를 연결하는 엣지 데이터가 있고, 노드와 엣지는 필요한 프로퍼티를 갖습니다.

graph LR
  M1((회원 1)) -->|추천| P1((상품 1))
  M2((회원 2)) -->|추천| P1
  M2 -->|추천| P2((상품 2))

소셜 네트워크는 그 자체가 그래프이고, 사용자 관계에 기반한 친구 추천이나 사용자 활동에 기반한 상품 추천, 관계 패턴을 이용한 실시간 이상 사용 탐지에 씁니다.

NoSQL 도입 시 고려 사항

성능·확장성·고가용성·모델 유연함이라는 장점이 있지만 RDBMS 대신 NoSQL을 고를 때는 네 가지를 따져야 합니다.

고려 사항확인할 것대응
트랜잭션 지원 여부다수의 NoSQL은 RDBMS 수준의 트랜잭션을 지원하지 않음. 도입하려는 NoSQL이 ACID를 지원하는지 확인·검증원하는 수준이 아니면 애플리케이션에서 트랜잭션을 보완. RDBMS와 함께 쓸 때는 두 저장소 간 데이터 동기화까지 고려
데이터 모델 적합성NoSQL마다 지원하는 데이터 모델이 다름설문 조사처럼 질문·답변이 계층 관계인 모델은 문서 DB, 단순 캐시는 키-값 DB
확장성·성능 요구NoSQL은 확장성이 뛰어나고 빠르지만 높은 일관성 대신 궁극적 일관성(eventual consistency) 을 지원성능보다 일관성이 중요한 서비스라면 NoSQL의 일관성 특징이 요구를 충족하는지 검증
운영·개발 역량오래 쓰인 RDBMS와 달리 백업·모니터링·확장 등 관리가 복잡할 수 있음. SQL 조인에 익숙한 개발자는 NoSQL 데이터 모델을 어려워함팀이 가진 경험을 고려하고 필요하면 미리 학습

도입은 신중하게

새 기술을 알면 써 보고 싶어지지만 도입 이후 운영 단계까지 고려해야 하고, 인터넷에서 자료를 구하기 어려운 기술일수록 더 그렇습니다. 임시 저장 성격이 강한 데이터를 MongoDB에 넣었다가, 기능 중요도 대비 이점은 거의 없고 구조만 복잡해진 데다 도입한 인원의 퇴사로 운영 문제까지 생겨 결국 MongoDB를 걷어내고 단순한 방식으로 바꾼 사례가 있습니다.

CAP 정리

분산 시스템에서 다음 세 조건을 모두 만족하는 시스템은 존재하지 않는다는 것을 증명한 정리입니다.

  • 일관성(Consistency): 모든 노드가 같은 순간에 같은 데이터를 봅니다. 한 노드의 데이터가 변경되면 모든 노드의 데이터도 동일한 값으로 바뀝니다
  • 가용성(Availability): 모든 요청이 성공 또는 실패 결과를 반환합니다
  • 분할내성(Partition tolerance): 네트워크 장애가 발생해도 시스템이 계속 동작합니다

세 조건 중 최대 두 가지만 충족할 수 있으므로 DB를 세 종류로 나눌 수 있습니다.

조합우선하는 것네트워크 분할이 발생하면대표
CA모든 노드에서 일관성과 가용성. 모든 노드가 변경된 최종 값을 쓰고 일부 노드가 다운되어도 나머지는 정상 동작(분할내성을 제공하지 않음)RDBMS
AP가용성 + 분할내성일관성을 포기하고 기능을 계속 제공Cassandra
CP일관성 + 분할내성일관성을 보장할 수 없으므로 분할이 해결될 때까지 일부 또는 전체 기능을 차단MongoDB

NoSQL은 분산 시스템을 기반으로 하므로 분할내성이 기본 입니다. 따라서 남는 선택은 가용성(AP)이냐 일관성(CP)이냐이고, 서비스의 품질 속성에서 둘 중 무엇에 중점을 두느냐에 따라 고를 수 있는 NoSQL이 달라집니다.

비교 / 트레이드오프

RDBMSNoSQL
확장수직 확장 (샤딩은 서로 다른 DB의 집합)수평 확장 (클러스터가 개념적으로 하나의 DB)
일관성·트랜잭션강한 일관성, ACID궁극적 일관성, ACID 일부 미지원
데이터 모델관계형, 조인용도별 모델(키-값·문서·칼럼 패밀리·그래프), 다수가 조인 미지원
스키마고정없거나 유연
CAPCAAP 또는 CP
운영오래 쓰여 자료·경험 풍부백업·모니터링·확장 관리가 복잡할 수 있고 팀 역량에 의존

내 생각

  • 대부분의 팀은 이미 NoSQL을 쓰고 있습니다. 레디스입니다. 세션 저장, 캐시, 분산 잠금, pub/sub 전부 키-값 DB 활용이므로, 실제 도입 논의는 “NoSQL을 쓸 것인가”가 아니라 “저장소를 하나 더 늘릴 만큼 RDBMS로 안 되는 요구가 있는가”입니다.
  • “유연한 스키마”를 “설계를 안 해도 된다”로 읽는 순간 사고가 납니다. 조인이 없으니 문서 DB는 읽기 패턴에 맞춰 데이터를 미리 중복시켜 두는 구조인데, 조회 패턴을 정하지 않고 넣기 시작하면 나중에 정합성 문제가 RDBMS보다 훨씬 크게 돌아옵니다. 문서 DB는 쓰기가 아니라 읽기부터 설계해야 합니다.
  • 분산 환경에서 P는 선택지가 아니라 주어진 조건입니다. 네트워크 분할은 막을 수 없으니 실제 질문은 “분할됐을 때 C와 A 중 무엇을 포기하나”입니다. RDBMS를 CA로 두는 것도 단일 노드 이야기이고, 주-복제 구조로 가면 복제 지연만큼 일관성을 이미 내주고 있습니다. Ch03의 “복제 DB에서 조회한 값으로 상태를 바꾸지 말라”는 경고가 정확히 이 지점입니다.
  • 도입 기준을 기술이 아니라 사람으로 세워야 합니다. MongoDB를 걷어낸 사례의 결정타는 성능이 아니라 담당자 퇴사였습니다. 팀 안에 그 저장소의 백업·복구·장애 대응을 해 본 사람이 둘 이상 없다면, 기술이 아무리 적합해도 운영 리스크가 이점을 넘어섭니다.

관련 개념

그래프 뷰