같은 목표, 다른 우선순위

데이터베이스 시스템의 종류는 데이터를 어떻게 표현하고, 무엇을 먼저 보장할지에 따라 갈립니다.

이 장의 분류는 제품 이름보다 저장 방식과 운영 선택을 먼저 읽는 것이 핵심입니다. 이후의 세부 DBMS는 아래 네 계열 중 어디에 무게를 두는지로 이해하면 됩니다.

계열

데이터를 보는 방식

운영에서 먼저 지키는 것

잘 맞는 문제

기본 축

RDBMS

테이블과 관계를 중심으로 정형 데이터를 관리

행·열·조인으로 같은 사실을 일관되게 표현

스키마, 제약조건, 외래키를 두고 여러 테이블의 관계를 SQL로 다룹니다.

강한 일관성, 트랜잭션, 표준화

주문, 결제, 회계처럼 틀리면 안 되는 상태를 안정적으로 보존하는 데 유리합니다.

정확한 업무 처리

은행, ERP, 핵심 서비스의 주 데이터처럼 무결성이 우선인 경우

분화

NoSQL

키, 문서, 컬럼, 그래프처럼 접근 패턴별 모델을 선택

한 가지 표보다 데이터 형태에 맞춘 모델

문서는 중첩 구조를 그대로 담고, 그래프는 관계 자체를 직접 저장하는 식으로 단순화합니다.

수평 확장, 유연한 구조, 패턴별 최적화

일부 제약을 줄이는 대신 대용량 분산 처리와 빠른 확장을 우선합니다.

로그, 세션, 피드, 소셜 관계

정형화가 덜 되어 있거나 특정 읽기·쓰기 패턴이 압도적인 경우

절충

NewSQL

관계형 모델을 유지하면서 분산 시스템으로 확장

SQL과 ACID를 버리지 않고 여러 노드로 확장

관계형 개발 경험을 유지하면서도 클러스터 단위의 운영을 목표로 합니다.

강한 일관성과 확장성의 동시 확보

단일 서버 RDBMS의 한계를 넘되, 애플리케이션 쿼리 모델은 크게 바꾸지 않으려는 선택입니다.

글로벌 서비스, 분산 트랜잭션

여러 지역에 데이터를 두면서도 관계형 질의와 일관성을 유지해야 하는 경우

특화

특수 목적 DB

특정 workload 하나를 매우 잘 처리하도록 설계

질의 방식에 맞춘 전용 구조

시계열 압축, 역인덱스, 벡터 인덱스처럼 저장 구조 자체가 문제 유형에 맞춰집니다.

도메인별 성능과 운영 효율

범용성보다 특정 분석, 검색, 추천, 관측 작업을 빠르게 수행하는 데 집중합니다.

모니터링, 전문 검색, RAG

시계열 DB, 검색 엔진, 벡터 DB처럼 문제의 형태가 명확한 경우

이 절의 읽는 법

데이터베이스의 역사는 “더 많은 데이터를, 더 빠르게, 더 안정적으로” 처리하려는 요구가 어떤 계열을 낳았는가의 흐름입니다. 이후 섹션은 이 네 계열을 더 깊게 파고드는 확장 설명으로 보면 됩니다.