주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 ‐ NoSQL 이해하기 - thought-corner/backend-roadmap GitHub Wiki
NoSQL이란
- 특정 요구사항에 맞춰 데이터를 저장하고 조회하기 위한 기법을 제공하는 데이터베이스를 NoSQL이라고 한다.
- NoSQL 데이터베이스는 전통적인 관계형 데이터베이스보다 덜 제한적인 일관성 모델을 이용하는 데이터의 저장 및 검색을 위한 메커니즘을 제공한다. 이런 접근에 대한 동기에는 디자인의 단순화, 수평적 확장성, 세세한 통제를 포함한다.
- NoSQL 데이터베이스는 단순 검색 및 추가 작업을 위한 매우 최적화된 키-값 저장 공간으로 레이턴시와 처리량과 관련하여 상당한 성능 이익을 내는 것이 목적이다. NoSQL 데이터베이스는 빅데이터와 실시간 웹 애플리케이션의 상업적 이용에 쓰인다.
- 데이터 시스템에서 NoSQL을 사용하는 주된 이유는 다음과 같다.
- 대용량 데이터나 분산 처리 필요성
- 고속 읽기와 쓰기 성능
- 특정 요구사항에 맞는 데이터 설계
- 비정형 데이터 처리 또는 유연한 스키마
- 관계형 데이터베이스로도 수평 확장은 가능하다. NoSQL의 클러스터는 개념적으로 데이터베이스가 하나라면 RDBMS는 서로 다른 데이터베이스 10개를 사용하는 것과 같다.
- 클러스터에서는 노드 중 하나가 발생하더라도 전체 클러스터가 정상 동작할 수 있으나 샤딩으로 구성한 RDBMS는 데이터베이스 중 하나에 장애가 발생하면 해당 데이터베이스에 속한 데이터를 사용할 수 없게 된다.
NoSQL 종류
- NoSQL을 나누는 다양한 기준이 존재하는데 일반적으로 4가지 유형으로 나눈다.
- 키-값 DB : 세션 관리(인증 토큰과 같은 세션 정보를 저장), 캐시(자주 사용하는 데이터를 캐싱하는 용도로 사용), 설정 관리(설정은 키-값 형태를 가지므로 관리하기에 적합)
- 문서 DB : 컨텐츠 관리(유연한 스키마를 이용해서 다양한 종류의 컨텐츠를 관리), 제품 카탈로그(다양한 메타데이터를 가진 카탈로그를 제공)
- 칼럼 패밀리 DB : 채팅 플랫폼 채팅 메시지나 IoT 데이터 등 대규모 데이터에 대한 조회와 저장이 필요한 서비스
- 대규모 데이터 관리(각 DB마다 데이터 구조에 약간 차이가 있지만 각 행이 여러 칼럼을 가질 수 있다. 여러 칼럼들을 그룹으로 묶어 관리한다.
- 그래프 DB : 소셜(소셜 네트워크 자체), 추천(사용자 관계에 기반한 친구 추천, 사용자 활동에 기반한 상품 추천 등), 부정 탐지(관계에 대한 패턴을 이용해서 실시간으로 이상 탐지)
NoSQL 도입 시 고려사항
- 트랜잭션 지원 여부 고려 : 다수의 NoSQL은 RDBMS가 지원하는 수준의 트랜잭션을 지원하지 않는다. 따라서 트랜잭션이 필요한 기능을 구현할 때는 도입하려는 NoSQL이 ACID를 지원하는지 확인하고 검증해야 한다. NoSQL이 원하는 수준의 트랜잭션을 지원하지 않으면 애플리케이션에서 따로 트랜잭션을 보완해야 한다. 또한 RDBMS와 NoSQL을 함께 사용할 경우 두 데이터 저장소 간의 데이터 동기화도 고려해야 한다.
- 데이터 모델이 요구사항에 적합한지 확인해야 한다 : NoSQL마다 지원하는 데이터 모델이 있다. 어느 모델을 사용할 것인지 설계가 필요하다.
- 확장성과 성능 요구 : NoSQL은 RDBMS와 대비해서 확장성이 뛰어나고 속도가 빠르다. 대신 높은 일관성을 지원하는 RDBMS와 달리 궁극적 일관성(Eventual Consistency)을 지원한다. 따라서 성능보다 일관성이 중요한 서비스에서는 NoSQL이 요구사항을 충족하는지 확인해야 한다.
CAP 정리
- Consistency(일관성) : 모든 노드가 같은 순간에 같은 데이터를 볼 수 있다. 한 노드의 데이터가 변경되면 모든 노드의 데이터도 동일한 값으로 바꾼다.
- Availability(가용성) : 모든 요청이 성공 또는 실패 결과를 반환할 수 있다.
- Partition Tolerance(분할내성) : 네트워크 장애가 발생해도 시스템이 계속 동작할 수 있다.
❗분산 시스템의 주요 일관성 모델
- 강한 일관성(Strong Consistency) : 쓰기가 끝난 순간부터 누가 읽어도 최신값을 보장할 수 있다. 전역 시계 기준 실시간 순서까지 보장하기에 가장 비싸고 느리다.
- 예시 : 계좌 잔액·이체, 재고 차감, 예약 좌석 선점
- 최종적 일관성(Eventual Consistency) : 순서 보장을 아예 포기. 노드마다 잠깐 다른 값을 볼 수 있지만 새로운 쓰기가 없으면 언젠가 모두 같은 값을 볼 수 있다.
- 예시 : SNS 팔로워 수·좋아요·조회수, 추천 피드, DNS 전파
결론 : 잠깐 틀린 값을 보여줘도 되는가? → 안 된다면 강한 일관성, 된다면 최종적 일관성