NoSQL, Redis

5주차 Database Study

 

MongoDB

NoSQL 데이터베이스

 

MongoDB의 특징

• 스키마 리스 : 비정형 데이터를 저장
• 샤딩 : 데이터를 여러 서버에 나누어 저장하는 수평 확장 방식, 쿼리(조회)시 통합된 결과를 제공

비정형 데이터란 사전 정의된 규칙이 없는 데이터

 

MongoDB가 데이터를 저장하는 형식

BJSON(Binary JSON) 형태로 데이터를 저장

 

BJSON과 JSON의 차이

JSON은 텍스트 형태로 저장되는 반면, BJSON은 이진형식으로 이루어져있다
이진형식으로 저장되어있어 BJSON은 MongoDB와 같은 툴을 이용해 읽어야함

텍스트 형식으로 저장되는 JSON과 달리 BJSON은 공간 및 처리속도가 빠르다

 

 

MongoDB 구조

• Document : 데이터를 저장하는 최소 단위 = Row
• Collection : Document의 집합 = Table

//Collection
[
  { "id": 1, "name": "John Doe", "age": 30, "address": "123 Main St" },
  { "id": 2, "name": "Jane Smith", "age": 25, "address": "456 Elm St" }
]

//Document
{ "id": 1, "name": "John Doe", "age": 30, "address": "123 Main St" }

 

 

RDBMS와의 차이점

조인

• RDBMS는 연관관계를 조인
• MongoDB에서는 연관된 데이터를 한번에 저장하는 방식

 

스키마

• RDBMS는 스키마에 제약이 있기 때문에 모든 ROW가 동일한 제약조건을 가짐
• MongoDB는 스키마리스이기 때문에 모든 Document가 동일한 속성을 갖지 않아도된다

//Document가 모두 동일할 필요가 없다

[
  { "_id": 1, "name": "John Doe", "age": 30, "address": "123 Main St" }
  { "_id": 2, "name": "John Doe", "age": 30, "address": "123 Main St", "city": "Suwon"}
]

 

MongoDB 언제 사용하지

• 연관관계가 복잡하지 않은 경우 → 조인이 필요없는 경우
• 데이터모델이 자주 변경될 때 = 요구사항이 복잡할 때? → 스키마 리스

 

Polyglot Persistence

여러 종류의 데이터베이스를 함께 사용해야하는 경우

→  단일 애플리케이션도 가능하고 여러 애플리케이션이 있는 복잡한 서비스에서도 가능함

 

 

Polyglot Persistence 장점

다양한 케이스에 대해서 유연한 대응이 가능

• 읽기 작업이 많은 케이스에는 NoSQL을 사용하여 읽기 작업 성능을 향상
• 반대로 복잡한 트랜잭션 연산이 필요한 경우에는 RDBMS로 무결성을 보장

 

CQRS(Command Query Responsibility Segregation)

읽기 작업과 쓰기 작업을 분리하는 패턴

→  읽기 모델과 쓰기 모델을 서로 분리하는 방식

 

 

왜 분리하는가?

쓰기는 Bounded Context 내부 규칙을 지키기 때문에 외부 컨텍스트와 직접 의존을 피함

읽기는 이러한 규칙이 느슨하기 때문에 여러 컨텍스트의 데이터를 조인할 수 있음

 

CQRS 패턴으로 분리시 예시

쓰기 작업 → 주문, 주문이력 엔티티만 결합(Bounded Context) 
읽기 작업 → 상품, 주문, 사용자 서로 다른 범위에 있는 엔티티들이 결합

 

CQRS 패턴의 종류

1. 단일 데이터베이스

ACID 트랜잭션을 하나의 DB에서 다룸

• 일관성 보장
• 하지만 읽기 쓰기 작업이 서로에게 영향을 미침

2. 데이터베이스 분리

Master Slave 구조

• 각 작업에 대한 부하 분산
• Master의 기록이 Slave에 동기화되는데 지연이 발생할 수 있음

3. 이벤트 소싱

데이터 변경 내용을 기록하고 이벤트 핸들러를 통해 기록하는 방식

• 이벤트 로그를 통해 변경이력을 추적할 수 있음
• 복잡한 구현 및 유지보수

 

최종 일관성 모델 vs 강한 일관성 모델

• 강한 일관성 모델 : 트랜잭션이 완료되면 모든 시스템이 일관된 데이터를 유지 →  RDBMS 
• 최종 일관성 모델 : 변경되었을 때 다른 복제본들도 동기화를 하게되지만 즉시 이루어지지는 않음, 하지만 최종적으로는 모두 동기화가 되어 일관성있는 상태를 유지 → NoSQL

 

Redis

인메모리 데이터 저장소

 

Redis의 특징

• Key-Value 구조 기반 데이터 처리
• 메모리에서 데이터를 처리하기 때문에 디스크 기반 데이터베이스보다 성능이 좋음
• String, List, Set, JSON 등 다양한 데이터 타입 지원

 

Redis의 주요 유즈케이스

사용자 세션

사용자의 세션 혹은 인증토큰을 Redis에 저장하고 여러 서비스에서 접근하여 유효성을 파악

TTL을 사용하여 세션 데이터를 만료, 로그아웃시 세션 키를 삭제

 

 

유저 랭킹

Redis의 ZSET 자료구조를 이용하여 점수를 기준으로 정렬된 리스트 생성

 

 

Redis 영속성

데이터를 디스크에 저장하여 장애 발생시, 데이터를 복구할 수 있게 해준다

• RDB(Redis Database Snapshots): 메모리에서 디스크로 주기적으로 덤프, 백그라운드로 동작하므로 덤프 도중에도 작업
• AOF(Append-Only File) : 모든 쓰기 명령을 로그로 기록하는 방식

RDB는 주기적으로 스냅샷을 만드므로 주기가 길다면 데이터 손실 있을 수 있음
AOF는 모든 쓰기 명령을 기록하기 때문에 로깅시 성능 저하 발생있을 수 있음

백업과 성능은 트레이드 오프 관계

 

 

Redis는 싱글스레드

Race Condition 발생을 방지하기 위해서 싱글스레드 사용

싱글스레드로 동작하게 되면 한번에 하나의 명령어만을 처리한다

만약, 멀티스레드로 동작하게되면 동시성 문제를 해결하기 위해 락이나 동기화가 필요하고 빠른 응답 시간을 보장할 수 없음

 

싱글스레드인데 더 빠른 이유

싱글스레드이기 때문에 동시성 문제를 걱정할 필요가 없음
디스크 I/O없이 메모리에서 읽고 쓴다

디스크 I/O 기반(MySQL)
1. 사용자가 쿼리 요청 2. 디스크에서 데이터를 찾아서 3. 메모리로 올린 후 4. 응답

메모리 기반(Redis)
1. 사용자가 명령 요청 2. 메모리에서 바로 응답