[주니어 백엔드 개발자가 반드시 알아야 할 실무 지식] 부록 B NoSQL 이해하기

• 💡해당 게시글은 최범균님의 ‘주니어 백엔드 개발자가 반드시 알아야 할 실무 지식’을 개인 공부목적으로 메모하였습니다.

NoSQL이란

NoSQL의 정의

• Not Only SQL
  • RDBMS의 한계(데이터양, 분산 처리 등)를 극복하기 위해 등장한 비관계형 데이터 저장소
• 특징
  • 스키마가 없거나 유연하며, 분산 환경에서의 확장성(Scale-out)을 최우선으로 설계됨

NoSQL 데이터베이스 정의

• 전통적인 RDBMS보다 덜 제한적인 일관성 모델을 이용하는 데이터의 저장 및 검색을 제공함
• 디자인의 단순화, 수평적 확장성, 세세한 통제를 목표로 함

RDBMS와 NoSQL의 특징 비교

• 주요 차이점
  • RDBMS
    • 데이터 정합성(ACID)과 복잡한 조인 연산에 최적화
  • NoSQL
    • 대용량 데이터의 고속 처리와 수평 확장에 최적화

• 주요 확장성 비교

  특징	RDBMS	NoSQL
  확장 방식	수직 확장 (Scale-up)	수평 확장 (Scale-out)
  데이터 처리	단일 서버	분산 처리
  스키마	고정 스키마	유연한 스키마
  일관성	강한 일관성 (ACID)	최종 일관성 (BASE)

  

수평 확장과 샤딩

• 확장성 확보 방식
  • Cassandra나 HBase 등이 이런 확장을 갖춤
  • 수평 확장을 통해 데이터 저장 용량을 늘릴 수 있음
  • NoSQL은 인메모리로 관계형 데이터베이스가 수직 확장을 통해 용량을 늘리는 것과 비교됨

  

• 샤딩과 NoSQL 비교
  • RDBMS의 샤딩(Sharding)
    • 관계형 데이터베이스로 수평 확장을 할 수 있지만, 10개의 데이터베이스를 구성하면 각 데이터베이스에 데이터를 사람이 직접 분배해야 함
  • NoSQL
    • 초기부터 분산 처리를 염두에 두고 설계되었으므로, 데이터베이스가 하나인 RDBMS를 샤딩하여 10개를 사용하는 것보다 훨씬 효율적임
  • RDBMS는 노드를 늘려도 그 중 하나에 장애가 발생하면 전체 클러스터에 영향을 줄 수 있음
• NoSQL 활용이 적합한 경우
  • 높은 처리량과 응답 속도
    • RDBMS로는 감당하기 힘든 대규모 트래픽이나 실시간 로그 데이터를 처리해야 할 때 적합함
  • 데이터 일관성 트레이드오프
    • RDBMS의 엄격한 ACID 트랜잭션 대신, 최종 일관성을 허용하더라도 가용성과 성능이 최우선인 서비스에 유리함
  • 유연한 확장
    • 정해진 스키마 없이 데이터를 저장해야 하거나, 트래픽 폭주 시 수평 확장이 빈번하게 필요한 경우 활용됨

NoSQL 종류

NoSQL의 4가지 유형

• 유형별 분류
  • 키-값 DB
  • 문서 DB
  • 컬럼 패밀리 DB
  • 그래프 DB

키-값 DB (Key-Value DB)

• 개념
  • 가장 간단한 형태의 NoSQL
  • 자바의 Map처럼 키와 값을 매핑해서 저장
• 대표적인 키-값 DB
  • DynamoDB
  • Redis (인메모리 키-값 저장소)

• 주요 용도
  • 세션 관리
    • 인증 토큰과 같은 세션 정보를 저장
  • 캐시
    • 자주 사용하는 데이터를 캐싱하는 용도로 사용
  • 고성능 처리
    • 단순한 구조로 빠른 읽기/쓰기가 필요한 경우

레디스의 특징

• 레디스는 단순히 키-값 외에 다양한 형태의 값을 지원함
• 정렬된 집합을 제공하는데 이를 사용하여 순위표를 쉽게 구현할 수 있음
• 메시지 큐 기능도 제공하고 있어 메시지 시스템으로도 활용이 가능함

문서 DB (Document DB)

• 개념
  • 데이터를 문서 (주로) JSON과 유사한 문서에 저장
  • 대표적인 문서 DB로는 MongoDB
• MongoDB
  • BSON (바이너리 JSON) 형태로 데이터를 저장
  • 스키마가 고정되어 있지 않음
  • JSON 형태면 되므로 RDBMS의 테이블과 달리 복잡하고 중첩된 모델을 쉽게 표현할 수 있음

  

• 장점
  • 새로운 속성 필요하면 추가하면 되므로 더 유연하고 구조나 배열을 사용할 수 있음
  • 어플리케이션에서 사용하는 데이터 모델과 DB에서 사용하는 데이터 모델이 거의 일치함
• RDBMS와의 비교
  • RDBMS에서는 중첩 개념적으로 하나의 모델을 지원하기 위해 여러 데이터를 사용하곤 함
  • 새로운 속성하려면 추가하면 되고 중첩된 구조나 배열을 사용할 수 있음

컬럼 패밀리 DB (Column Family DB)

• 개념
  • 키-값 DB의 확장 버전이라고 볼 수 있음
  • 대표적인 컬럼 패밀리 DB에는 Cassandra와 HBase가 있음
• 구조
  • 각 DB마다 데이터 구조에 약간 차이가 있지만 각 행은 여러 컬럼들을 그룹으로 묶어 관리한다는 공통점이 있음

  

• 주요 용도
  • 대규모 데이터 관리
    • 웹 사용자 행동 로그, IoT 센서 데이터 등 대규모 데이터에 대한 빠른 쓰기와 조회가 필요한 서비스에서 사용함

• 칼럼 기반 DB

  

칼럼 기반 DB

• 칼럼 기반(Column-oriented) DB 또는 칼럼형(Columnar) DB는 칼럼 패밀리 DB와는 다름
• RDBMS에서 데이블은 일반적으로 데이터를 저장할 때 Row 단위로 데이터를 저장함
• 칼럼 단위로 데이터를 저장하는 것은 OLAP와 같이 데이터 분석 목적으로 주로 사용됨
• 칼럼 기반 DB로는 Clickhouse와 MariaDB의 ColumnStore 등이 있음

그래프 DB (Graph DB)

• 개념
  • 그래프 이론 그대로 데이터를 그래프 형태로 관리
  • 노드 데이터가 있고 노드와 노드를 연결하는 엣지가 있다

• 주요 특징
  • 소셜
    • 소셜 네트워크는 그 자체가 그래프임
  • 추천
    • 사용자 관계에 기반한 친구 추천, 사용자 활동에 기반한 상품 추천 등에 활용할 수 있음
  • 부정 탐지
    • 관계에 대한 패턴을 이용해서 실시간으로 이상 사용을 탐지할 수 있음
• 대표 그래프 DB
  • Neo4j (가장 대표적)
  • OrientDB
• 그래프 DB의 장점
  • 그래프 데이터를 그대로 저장해 관리함
  • 노드와 엣지로 데이터의 관계를 표현함
  • 노드와 엣지는 필요한 프로퍼티를 가짐
  • 대표적인 그래프 DB로는 Neo4j가 있음

NoSQL 도입 시 고려 사항

NoSQL의 장점과 단점

• 장점
  • 대용량 데이터 처리 속도, 유연한 스키마, 수평 확장 용이성(Scale-out)
• 단점
  • 트랜잭션(ACID) 지원 미흡, 데이터 일관성 보장의 어려움, 운영 복잡도 증가

도입 전 핵심 검토 사항

• 트랜잭션 요구사항 확인
  • 금융 거래나 재고 관리처럼 강력한 트랜잭션이 필요한지 검토해야 함
  • NoSQL이 ACID를 지원하는지, 혹은 애플리케이션 레벨에서 해결 가능한지 확인이 필요함
• 데이터 모델 적합성 검증
  • 데이터 간의 관계가 복잡한지, 아니면 문서나 키-값 형태로 단순화 가능한지 확인해야 함
  • 관계가 복잡하다면 RDBMS나 그래프 DB가 더 적합할 수 있음
• 확장성과 성능 요구사항 분석
  • 향후 데이터 증가량과 트래픽 예측을 통해 수평 확장이 반드시 필요한지 판단해야 함
  • 단일 서버로 처리가 불가능한 수준의 대용량 데이터인지 검토가 필요함
• 운영 및 기술 역량 확보
  • 팀 내에 NoSQL 운영 경험이 있는지, 장애 발생 시 대처 가능한지 확인해야 함
  • 필요하다면 기술 검증(PoC)과 학습 기간을 거쳐야 함

CAP 정리

CAP 정리란

• CAP 정리(CAP Theorem)
  • 분산 시스템에서 중요하게 여겨지는 이론
  • 세 가지 조건을 모두 만족하는 분산 시스템은 존재하지 않는다는 것을 증명한 정리

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

CAP 정리의 의미

• CAP 정리에 따르면 위 조건 중 최대 2가지만 충족할 수 있음

CAP 정리에 따른 DB 분류

• CA (일관성 + 가용성)
  • 모든 노드에서 일관성과 가용성을 제공하지만, 분할 내성은 없음
  • 네트워크 장애가 없을 때만 유효하며, 장애 발생 시 전체 시스템에 영향을 줄 수 있음
  • 전통적인 RDBMS가 이에 해당함
• CP (일관성 + 분할내성)
  • 가용성보다는 데이터의 일관성을 최우선으로 함
  • 네트워크 분할(Partition) 발생 시, 데이터 일관성을 유지하기 위해 일부 서비스의 가용성을 희생함
  • MongoDB, HBase 등이 이에 해당함
• AP (가용성 + 분할내성)
  • 일관성보다는 서비스의 가용성을 최우선으로 함
  • 네트워크 분할이 발생해도 서비스는 계속 동작하며, 데이터는 나중에 동기화됨 (최종 일관성)
  • Cassandra, DynamoDB 등이 이에 해당함

• NoSQL과 CAP
  • NoSQL은 분산 시스템을 기반으로 하므로 분할내성(P)을 기본으로 함
  • 따라서 서비스 목적에 따라 가용성(AP)과 일관성(CP) 중 하나를 선택해야 함
  • 서비스의 품질 속성에 맞춰 가용성과 일관성 중 무엇이 더 중요한지 판단하여 적절한 NoSQL을 도입해야 함

NoSQL 선택 가이드

사용 사례별 NoSQL 선택

도입 시 주의사항

• NoSQL 도입을 신중하게
  • 새 기술에 대한 호기심으로 무작정 도입하는 것은 위험함
  • NoSQL은 RDBMS와 대비해서 성능과 타협을 해야 할 수도 있으므로, 도입 시에는 성능 요구사항에 대해 신중을 기해야 함

• 대용량 서비스라고 해서 무조건 NoSQL이 정답은 아님
• 적절한 튜닝을 거친 RDBMS로도 충분한 경우가 많음
• MongoDB 같은 문서형 DB는 스키마가 유연하지만, 이로 인해 애플리케이션 레벨의 데이터 관리 복잡도가 증가할 수 있음
• 단순히 개발 편의성이나 유행을 따르기보다, 확실한 성능 이점이나 요구사항(예: 비정형 데이터)이 있을 때 도입하는 것이 바람직함

RDBMS와 NoSQL 선택 기준

고려 사항	RDBMS 선택	NoSQL 선택
트랜잭션	ACID 필수	최종 일관성 허용
데이터 구조	고정 스키마	유연한 스키마
확장성	수직 확장	수평 확장
일관성	강한 일관성 필요	성능 우선
쿼리	복잡한 조인 필요	단순 조회 위주
데이터 양	중소 규모	대용량
관계	복잡한 관계	단순한 관계

하이브리드 아키텍처 접근

• RDBMS와 NoSQL의 공존
  • RDBMS
    • 데이터의 무결성과 트랜잭션이 중요한 회원 정보, 결제 내역, 주문 데이터 등에 사용함
  • NoSQL
    • 대용량 트래픽 처리나 유연한 스키마가 필요한 로그성 데이터, 상품 리뷰, 소셜 피드 등에 사용함
  • 두 저장소를 적절히 조합하여 각 기술의 장점을 극대화하는 전략이 필요함

배운 점

• 단순히 RDBMS의 대체제가 아니라, 대용량 데이터와 분산 환경이라는 특수한 요구사항을 해결하기 위한 도구임을 배움
• CAP 정리에 따라 모든 것을 만족할 수는 없으며, 서비스의 특성에 맞춰 일관성과 가용성 중 하나를 선택해야 함을 이해함
• 스키마가 없어서 개발이 편리할 수 있지만, 데이터 정합성 관리나 운영 복잡도가 증가할 수 있다는 점을 인지함
• 무조건적인 최신 기술 도입보다는 데이터의 성격(관계형, 문서형, 키-값 등)에 맞는 저장소를 선택하는 안목이 중요함

Reference

• 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식