week03 - NoSQL, MongoDB, Mongoose, 3-Tier Architecure

[hyejungg]

🔥 알게된 점

1. NoSQL
2. MongoDB?!
3. Mongoose
4. 견고한 Node.js 프로젝트 설계
5. CRUD 실습

📚 배운 점

NoSQL, SQL?!

SQL : RDBMS의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어

NoSQL : 비관계형 데이터베이스로 비정형 데이터를 처리할 수 있는 유연한 스키마 제공
// Not-Only SQL (sql뿐만 아니라 여러 기능을 제공한다~)

SQL과 NoSQL차이

• NoSQL은 DB자체가 확장되고 분산하여 사용하기(수평적 확장)에 적합하게 되어 있음

NoSQL 특징

1. 표준화된 구조적 질의 언어(SQL)이 없음
2. 관계를 갖지 않음

언제 쓰지?

• 데이터의 수정 < 조회 가 많은 경우
• 비정형 데이터가 존재하는 경우 -> 유연한 구조
• 막대한 양의 트래픽을 다룰 경우 -> 수평적 확장

ex.

일관성이 중요한 은행시스템 : SQL (트랜잭션 처리 필요하므로) / 실시간 데이터 조회가 많은 SNS : NoSQL

MongoDB?

• document 지향 NoSQL
• JSON 형태의 동적 스키마형 document 사용

Document

• Database > Collection > Document > Field 계층으로 이뤄짐

• MongoDB에서 데이터를 저장하는 최소 단위
• 필드와 값의 쌍으로 구성
• 데이터 입출력 시 JSON 형식을 사용, 저장 시에는 BSON(Binary JSON) 변환
• 관계를 갖는 데이터의 경우 중첩 document, 배열, 컬렉션 분리 등으로 나타낼 수 있음

BASE

• Basically Available (가용성)
• Soft State (소프트 상태)
• Eventually Consistent (결과적 일관성)

MongoDB 데이터 모델링 어떻게?

Document 설계 -> Collection 설계 순으로 진행하면 편함!

• Embedded 방식 : 1개의 document안에 다 넣는 방식.
• References 방식 : RDBMS의 정규화한 느낌. (각 document는 외래키 같은 걸로 참조하는 형태)
  • 자식 참조 : 부모가 자식의 id를 배열 형태로 갖는 형태
  • 부모 참조 : 자식에서 부모의 id를 갖는 형태
  • 상호 참조 : 각각의 document가 id를 참조하는 형태

mongoDB는 참조가 많으면 조회 시나 쿼리를 날릴 때, 시간이 오래 걸릴 수 있어서 좋지 않음. join이 안되니까!!

어떤 걸 쓰는게 좋을까?

MongoDB 자주 사용하는 모델링 패턴

1. Extended Reference : 서로 다른 Collection에서 자주 사용되는 경우, 해당 일부를 내부에 임베드하여 저장하는 패턴

• 쿼리를 줄일 수 있음

2. Subset : 서로 다른 Collection에서 자주 사용되는 경우, 해당 일부를 내부에 임베드하여 저장하는 패턴
   • 다른 Collection에 있는 분리된 데이터이므로 Join이 어려움.
     • Join 할 수 있지만, 쿼리 조회 성능이 덜어질 수 있음
   • 조회 성능을 높이기 위해 미리 보여지는 데이터를 내부에 저장하는 패턴
     • 더보기를 누르기 전에 데이터들을 미리 임베드 시키는 형태
   • update 시 양쪽 모두 수정해야 함

Mongoose

• MongoDb ODM
• 비동기 환경에서 작동하도록 설계된 MongoDB 객체 모델링 도구 (promise, callback, async await 지원)
  참고문서- 공식 몽구스 문서

ORM vs ODM

ORM : Object Relational Mapping (객체와 관계형 데이터베이스 매핑) //시퀄라이즈, typeorm

ODM : Object Document Mapping (객체와 Document 매핑) //몽구스

견고한 NodeJs Project ⁉️

3 Layer Architecture

controller <-> service <-> data access(Mongoose)

• 비즈니스 로직과 Controller에서 분리

왜 분리?

독립적인 기능 수행 / 유지보수 / 확장성, 유연성을 위함

어떻게 분리?

비즈니스 로직 -> Service Layer로
Serivce Layer는 req, res 객체를 받지 않음
req, res는 Controller Layer에서

Contorller

• Model 처리 전 1차적으로 데이터 가공
• 비즈니스 로직 수행 후 다시 받은 데이터를 Response

Service

• Controller에서 받아온 데이터를 갖고 가공하여 DB에 접근 -> 결과값을 가져와서 가공
• 여기서 이루어지는 데이터 가공 과정은 비즈니스 로직

DTO (Data Transfer Object)

• 계층 간 데이터 교환을 위해 사용하는 객체
• Typescript에서는 Interface를 이용해 구현

[hyejungg]

디펜던시에서 @types 가 붙어야 typescript 사용 가능