[오동재] 데이터 중심 애플리케이션 설계 1주차

2024-designing-data-intensive-applications/1주차/오동재/1장-2장.md

@@ -0,0 +1,80 @@
+# 1. 데이터베이스 개요
+
+## 신뢰성
+
+결함이 있어도 장애가 없도록
+
+## 확장성
+
+시나리오를 확실히 하고 성능테스트를 하자
+
+- 성능테스트를 할 때 평균값이 아니라 중앙값을 사용하자
+  - 중앙값을 사용하면 사용자의 절반은 해당 중앙값보다 더욱 지연된다는 사실을 알 수 있음
+- tail latency : p95, p99, p999 등 꼬리 쪽 latency.
+  - 아마존 같은 경우는 이를 사용함.(구매를 많이할 수록 지연이 많이 될텐데 그들이 큰 손이기 때문)
+
+<aside>
+💡 response time vs latency
+- respons time : 요청 후 응답까지 걸린 시간, **클라이언트가 네트워크 요청을 하는 시간 등이 포함**됨
+- latency : 요청 후 client가 아무 행위도 하고 있지 않는 대기 시간
+
+</aside>
+
+## 유지 보수성
+
+추상화하자. 유지보수하기 쉽게
+
+# 2. 데이터 모델과 query
+
+## SQL
+
+기존에 추상화되어 있지 않고 잘 설계되지 않은 DB들을 압도
+
+### 장점
+
+- 조인 편리
+- 다대일 구현 편의
+- 다대다 구현 편의
+
+### 쿼리
+
+명령형이 아니라 선언형으로 쿼리
+
+어떻게 찾을 지는 optimizer가 해줌
+
+병렬처리에 적합
+
+## NoSQL
+
+SQL은 app과 db간의 타입이 불일치.
+NoSQL은 JSON등을 그대로 저장해서 이를 해결
+
+### 장점
+
+- 스키마 유연성
+- 지역성
+
+### 쿼리
+
+storage locality ⇒ 관계성이 없다면 쿼리가 빠름
+
+**map reduce**
+
+- 복잡한 쿼리를 사용하기 위해 함수를 사용하는 방식
+- map, reduce 함수는 db에 접근하지 않고 side effect가 없는 pure 함수여야 함
+- 근데 이런 map, reduce 함수를 동시에 작성하고 적용하기는 어려움
+  ⇒ aggregation pipeline 출시
+
+# 다대다, 검색과 관련된 과거 논쟁
+
+### 네트워크 모델, 계층 모델
+
+트리구조이기 때문에 쿼리하려면 트리에서의 탐색임.
+
+⇒ 최악의 경우 오래 걸림
+
+### 관계형 모델
+
+- query optimizer
+  - 쿼리를 쉽게 해줌(추상화되어있음)
+  - 이를 수정하면 추후 유지보수가 수월해짐