RDB와 NoSql 비교 및 장점 | AWS에서 제공하는 NoSql은?

나는 평소 관계형 데이터베이스인 Postgresql, mariaDB밖에 접하지 못했었다

하지만 지금 다니고 있는 회사 서비스의 트래픽이 늘어남에 따라 서버 분산을 할 필요가 절실해졌다

Postgresql에서 AuroraDB로 변경하며 스케일 업 하였고 AuroraDB에서 4대의 수로 늘리는 스케일 아웃을 적용했다.

(AuroraDB는 특정 시간에 트래픽이 몰리는 것에 특화되어 DB 수가 늘어나는 가용성이 보장되는 DB다)

하지만 이 마저도 우리 서비스의 트래픽으로 버티기가 힘들어 

매일 20만 건의 댓글이 달리는 DB 부하를 줄이기 위해 특정 도메인들을  NoSQL에 저장하고자 한다

MongoDB는 스키마와 동일한 JSON 형식으로 저장할 수 있어 개발 시 장점과
5배 이상의 성능을 끌어올릴 수 있다고 한다.

 

아래는 MongoDB를 공부하면서 알게 된 다른 종류의 NoSql과 장단점에 대해 설명한다.

 

RDB와 NoSql

RDB(ex: aurora, postgresql)

스토리지의 데이터가 모든 방향을 결정

정규화된 데이터 모델을 통해 애플리케이션이 종속되고

액세스패턴과 관계없이 모델링 구축

NoSql(ex: mongo)

데이터 처리 방식을 결정하고 나면

데이터 모델링을 하고

스토리지 형태를 결정

MongoDB

---

NoSql진영에서 가장 많이 사용

조회시 한 번에 다 읽어서 디스크 io 최소화

json을 다큐먼트 모델로 사용하기 때문에

실제 어플리케이션의 오브젝트와 스토리지의 데이터 1대 1 매치

애플리케이션이 정하는 스키마를 그대로 디비에 저장할 수 있기 때문에 자유로운 스키마 업그레이드 강점이 있음

조회 성능에 조인이 필요 없는 json구조로 성능 오버헤드 감소 이점

AWS에서 제공하는 NoSql

---

(아래는 AWS 공식 문서 발췌 내용)

Amazon DynamoDB는 서버리스 방식의 완전관리형 키-값 데이터베이스 서비스로, 10밀리 초 미만의 일관된 성능과 무제한 확장성을 제공합니다.

Amazon DocumentDB(MongoDB 호환)는 완전관리형 기본 JSON 도큐먼트 데이터베이스로서 인프라를 관리하지 않고도 규모와 관계없이 중요한 문서 워크로드를 쉽고 비용 효율적으로 운영할 수 있게 해 줍니다.

Amazon Neptune은 뛰어난 확장성과 가용성을 제공하도록 설계된 서버리스 방식의 완전관리형 그래프 데이터베이스 서비스로, 수십억 개의 관계를 몇 초 만에 쿼리 할 수 있습니다.

Amazon MemoryDB for Redis는 내구성이 뛰어난 인 메모리 데이터베이스 서비스로, 마이크로초의 읽기 및 쓰기 응답 시간을 통해 초고속 성능을 달성합니다.

Amazon ElastiCache는 Redis 및 MemCached와 호환되는 완전관리형 인 메모리 데이터 스토어 및 캐시 서비스로, 비용에 최적화된 실시간 성능을 제공합니다.

Amazon Keyspaces(Apache Cassandra용)는 다중 리전 복제를 통해 최대 99.999%의 가용성을 제공하도록 설계된 서버리스 방식의 완전관리형 와이드 칼럼 데이터베이스입니다.

Amazon Timestream은 서버리스 형식의 완전관리형 시계열 데이터베이스로, 관계형 데이터베이스보다 1,000배 더 빠른 속도로 하루 수조 건의 이벤트를 손쉽게 저장하고 분석할 수 있습니다.

Amazon OpenSearch Service는 비즈니스 및 운영 데이터의 실시간 검색, 모니터링 및 분석을 지원하는 완전관리형 분산 검색 및 분석 제품군입니다.

DoumentDB, GraphDB, In memoryDB

---

DocumentDB(AWS MongoDB)

데이터를 JSON 혹은 유사 형식의 문서로 데이터를 저장 및 쿼리
각 어플리케이션에서 사용하는 모델 형식을 그대로 사용 가능 (Ex. JavaScript => JSON)
Nest 된 구조로 문서를 저장

• 사용 사례
  컨텐츠 관리 : 비디오 및 블로그 포스팅등의 관리 및 추적

GraphDB(AWS Neptune)

데이터보다 데이터 간 관계가 더 중심인 데이터베이스입니다.
각 데이터 주체간 관계와 연결을 분석하는데 최적화

사용 사례
소셜 네트워크: 각 사람 간의 친구관계, 팔로우 관계등을 정의할 때 사용
이상탐지: 구매자가 평소에 구매하지 않는 물품의 구매 등에 대한 감지 혹은 패턴을 파악할 때 사용
추천 엔진: 누가 무엇을 구매했는지 혹은 어떤 그룹의 사람들이 어떤 성향을 가지고 있는지를 파악

InMemoryDB

메모리를 사용한 데이터베이스
SSD 혹은 HDD에 저장하는 것이 아닌 메모리에 저장하기 때문에 읽고 쓰기가 매우 빠름
SSD 혹은 HDD에 비해서는 내구성이 떨어짐

 

사용 사례
실시간 경매: 매우 빠른 I/O및 응답속도가 빠른 수만 명이 사용하는 경매 시스템에 사용
게임의 랭킹 보드: 실시간으로 매우 빠르게 변하는 랭킹시스템에 사용
캐싱: 자주 요청받는 메인 데이터베이스(주로 관계형 DB)의 쿼리를 임시로 저장하여 빠른 속도로 유저에게 제공할 때 사용

AWS 서비스

 

Amazon Elasticache
메인 데이터베이스의 워크로드를 분산하고 캐싱 기능으로 활용
쿼리 캐싱, 세션 저장, 임시 데이터 저장 등등

Amazon MemoryDB for Redis : 내구성을 확보한 In-Memory DB 서비스
메모리 데이터베이스로 메인 데이터베이스 자체로 사용
타임시리즈 데이터베이스, IOT 기기들의 메인 데이터베이스로 사용

 

현재까지 디비 부하를 줄이기 위해 RDS Proxy를 적용하고, AuroraDB로 변경하였다.

또 다른 부하 분산 방법으로 샤딩이 있다고 하는데, 아직은 Aurora로 버티고 있고, 

DB 자체를 변경해야 한다고 내부적으로 생각을 하고 있다. 

현재 태스크가 너무 많아서 언제 적용할지 모르지만 적용하게 된다면 도입 방법과 도입 이후 부하 변화를 포스팅을 하겠다

 

 

글을 읽고 도움이 되었다면 좋아요 하나 눌러주세요

야근하는 직장인에게 큰 도움이 됩니다.