무엇을 한 단위로 저장하느냐가 갈림점입니다

NoSQL 4종은 저장 단위와 빠른 조회 방식이 서로 다릅니다

같은 사용자 데이터라도 키 하나를 바로 읽을지, 문서 내부를 조건 검색할지, 넓은 행을 열 묶음으로 확장할지, 관계를 따라 탐색할지에 따라 모델 선택이 달라집니다.

비교 축
단건 응답

키-값

키 하나로 값을 바로 찾는 모델

유연한 구조

문서

JSON 같은 문서 전체를 저장하는 모델

대량 쓰기

컬럼 패밀리

행 아래에 필요한 열 묶음을 붙여 가는 모델

관계 탐색

그래프

노드와 엣지를 함께 저장하는 모델

저장 단위 키 1개 + 값 1개"user:1001" -> {...} 문서 1개{ user, orders, address } 행 1개 + 열 묶음row key + profile/activity 노드 + 관계(사용자)-[구매]->(상품)
빠른 작업 키로 단건 조회, 캐시 조회 문서 내부 필드 조건 검색 넓은 행 범위 읽기, 대량 이벤트 쓰기 연결을 여러 단계 따라가는 질의
잘 맞는 상황 세션, 장바구니, 실시간 카운터 사용자 프로필, 콘텐츠, 상품 카탈로그 로그, 시계열, IoT, 분석성 데이터 추천, 소셜 그래프, 사기 탐지
선택 기준 지연 시간을 가장 짧게 줄이고 싶을 때 레코드마다 필드 구조가 조금씩 달라도 될 때 수평 확장과 쓰기 처리량이 가장 중요할 때 조인보다 관계 자체를 저장해 추적할 때
핵심: 조회 기준이 면 키-값, 문서 내부 필드면 문서, 넓은 행과 대량 쓰기면 컬럼 패밀리, 연결 추적이 핵심이면 그래프를 먼저 떠올리면 됩니다.