Blocking vs Non-Blocking
Blocking
- 자신의 작업을 진행하다가 다른 주체의 작업이 시작되면 해당 작업이 끝날때까지 기다렸다가 자신의 작업을 실행
- 제어권을 바로 돌려주지 않는 경우
Non-Blocking
- 다른 주체의 작업에 상관없이 자신의 작업을 하는 것
- 제어권을 바로 돌려주는 경우
Synchronous vs Asynchronous
Synchronous
- 작업이 끝나는 동시에 시작하는 것
- 순서와 결과가 정해짐
Asynchronous
- 끝나는 동시에 시작함을 보장하지 않는 것
- 순서가 보장되지 않음
Sync / Async / Blocking / Non-Blocking
1) Sync + Blocking
- Application에서 I/O 요청을 한 후 완료되기 전에는 Block되어 다른 작업을 수행할 수 없다
- Blocking되는 시간동안 자원이 효율적으로 사용되지 않음
→ Thread로 Block 문제를 해소할 수 있지만 Thread의 Context Switching 비용이 문제
2) Async + Blocking
- 다른 작업을 하다가 주기적으로 I/O 완료 상태를 확인 (Polling)
- 작업이 완료되기 전까지 주기적으로 호출되어 불필요하게 자원을 사용
- 완료 여부를 신경쓰지는 않지만 다른 일을 하지 못함
- MySQL + NodeJS 조합
3) Async + Non-Blocking
- I/O 요청 후 바로 return되고 I/O가 끝나면 callback으로 이후 작업이 진행
- NodeJS가 싱글 스레드 + 이벤트 루프로 구현한 작업
4) Sync + Non-Blocking
- 데이터를 가져올때 정보 로드율을 보여주는 경우와 비슷
- 자신의 작업을 처리하다가 결과가 리턴되면 해당 값 처리
SQL vs NoSQL
SQL
- 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위한 언어
- 엄격한 스키마를 원칙으로하며 스키마에 맞지 않는 형식의 데이터는 저장할 수 없다
- 데이터 사이의 관계를 지정하기 쉽다 (FK) → 중복없이 데이터를 다룰 수 있다
NoSQL
- SQL보다 덜 제한적인 데이터를 관리하기 위한 언어
- 다른 구조의 데이터를 저장할 수 있다
- 하나의 컬렉션에 관련 데이터를 모두 작성 → 중복된 데이터가 발생해 업데이트가 있는 경우 해당 데이터를 모두 업데이트해야한다
SQL vs NoSQL
SQL
- 관계를 맺고있는 데이터가 자주 변경되는 어플리케이션인 경우
- 엄격한 스키마가 중요한 경우
NoSQL
- 정확한 데이터 구조를 알 수 없거나 변경의 여지가 있는 경우
- 읽기 처리를 자주 하지만 변경을 자주 하지 않는 경우
NodeJS + NoSQL
- 단순한 작업의 I/O
- Blocking + Sync + 멀티스레드 : Context Switching때문에 불필요한 자원 소모
- Non-Blocking + Async + 싱글스레드 : 효율적 처리 가능
- MySQL은 복잡한 데이터를 I/O하게 되고 I/O의 순서가 보장되어야하는 경우가 많다 → 싱글 스레드로 사용하면 Non-Blocking + Sync상태가 되어 비효율적
- NoSQL은 단순한 I/O 처리에 적합 → NodeJS는 NoSQL과 어울린다
참고자료
https://siyoon210.tistory.com/130
