선택 순서

먼저 데이터의 모양을 묻고, 그다음 자연스러운 DB 계열을 고릅니다.

출발점은 RDB냐 NoSQL이냐가 아니라, 지금 저장하려는 데이터가 행·열 구조인지, 문서형인지, 대량 적재형인지, 관계 탐색형인지를 먼저 구분하는 것입니다.

데이터가 이렇게 보이면

행·열 구조가 고정되고 관계가 자주 엮입니다

스키마가 안정적이고 여러 테이블을 함께 조회하거나 제약조건으로 규칙을 지켜야 합니다.

→
정형 데이터

RDB

조인, 무결성, 트랜잭션을 DB가 직접 책임지기 좋습니다.

예: 회계, 주문-결제, 인사 관리
데이터가 이렇게 보이면

문서마다 필드가 달라지고 JSON 중첩이 많습니다

구조가 자주 바뀌고 객체 하나를 문서 단위로 읽고 쓰는 일이 많습니다.

→
반정형 데이터

Document DB

문서 자체를 그대로 저장하므로 스키마 변화와 중첩 구조를 다루기 편합니다.

예: 상품 카탈로그, CMS, 설정 문서
데이터가 이렇게 보이면

로그·이벤트처럼 계속 쌓이고 빠르게 저장하는 일이 중요합니다

복잡한 관계보다 대량 쓰기, 분산 저장, 단순 조회 효율이 더 중요합니다.

→
비정형 데이터

Wide-Column / Key-Value

관계 모델링 부담을 줄이고, 큰 쓰기량과 단순 접근 패턴에 집중할 수 있습니다.

예: 로그 수집, 세션, 이미지 메타데이터
데이터가 이렇게 보이면

개체보다 연결과 경로 탐색이 더 중요합니다

누가 누구와 이어지는지, 어떤 경로로 닿는지가 질의의 핵심이 됩니다.

→
관계 중심 데이터

Graph DB

관계를 따라가는 탐색 자체를 저장 모델로 삼아 추천과 연결 분석을 더 직접적으로 처리합니다.

예: 추천 시스템, 소셜 그래프, 경로 분석
핵심: 같은 서비스 안에서도 주문은 RDB, 상품 속성은 Document DB, 로그는 Key-Value/Wide-Column처럼 데이터 역할별로 다른 선택이 자연스러울 수 있습니다.