유형 이름을 외워서 나열하는지, 아니면 데이터 모델·접근 패턴·일관성 요구를 묶어서 "왜 이 유형을 골랐는지"를 설명할 수 있는지를 가르려는 질문이다.
NoSQL은 단일 모델이 아니라 데이터 접근 패턴에 맞춰 갈라진 저장소 묶음이다. 키값은 단건 조회·캐시·세션처럼 키로 끝나는 워크로드를, 문서는 JSON 단위로 묶이는 유연 스키마를, 컬럼 패밀리는 와이드 로우의 대규모 분산 쓰기·분석을, 그래프는 관계 탐색을, 시계열은 시간 축 append-heavy 데이터를 노린다. 결국 유형 선택은 "어떤 쿼리가 가장 자주 도는가"를 먼저 정의해야 끊어진다.
RDBMS 하나로 버티다 캐시·문서 DB를 따로 빼본 경험이 있다면, 어떤 쿼리가 분리 기준이었는지로 답변을 풀 수 있다
MongoDB·DynamoDB 같은 문서 DB에서 모델을 잘못 잡아 재설계해 본 경험이 있다면, 접근 패턴 우선 설계의 근거로 연결된다
Redis를 캐시가 아니라 1차 저장소로 써본 경험이 있다면, 키값 DB의 한계와 장애 시나리오 이야기로 이어갈 수 있다
시계열·로그 데이터를 일반 RDBMS에 넣었다가 비용·쿼리 지연으로 터진 경험이 있다면, 유형 선택의 비용 측면 근거로 쓸 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.