대규모 스터디

DB 스케일 아웃 전략

대규모 서비스 OS 캐시 적중률을 높이기 위해 데이터량이 물리 메모리보다 적게 유지하는 것이 좋다. 따라서 대량의 데이터를 저장하는 테이블은 레코드가 가능한 작게 설계할 것

테이블 전략

정규화를 통해 테이블 분리해 테이블 자체의 레코드 수를 줄인다. 레코드 수를 줄여 필요한 부분만 OS캐시의 적중률을 높이는 방식으로 활용할 수 있다

인덱스를 통해 데이터 탐색 최소화

B트리 VISUAL 사이트 : https://www.cs.usfca.edu/~galles/visualization/BTree.html

B+트리 VISUAL 사이트 : https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html

B트리를 쓰는 이유

장점

B트리의 경우는 이분 트리 보다 자식의 수를 더 많이 가질 수 있으므로 전체 트리의 깊이는 낮아지는 장점이 있다.

자식수를 많이 가질 수 있으므로 블록으로 묶기 용이하다.( OS 블록(페이지) 단위로 읽기 때문에 디스크 I/O를 줄일 수 있다

.* B+ 트리

B- 트리에 순차적 탐색을 더 용이하게 해주는 자료 구조

모든 노드의 데이터는 리프노드에서 관리한다

리프노드는 연결리스트로 연결되어 있다.

장점 : 순차적 데이터 읽기 경우 리프 노드들이 연결리스트로 연결되었기 때문에 탐색에 용이하다

단점 : 모든 데이터가 리프 노드에 있기 때문에 부모 노드의 경우에도 리프노드 까지 탐색을 해야한다

MySQL 인덱스 적용

기본적으로 인덱스 사용되는 것 : where, order by, group by의 조건에 지정된 컬럼

인덱스 작용하는 것 : 명시적으로 추가한 인덱스, primary key, unique 제약 컬럼

*tip 단, 복수 컬럼에 동시에 인덱스를 태울때는 복합 인덱스를 사용해야한다

MYSQL은 한 번의 쿼리에서 하나의 인덱스만 사용하는 특성을 가지므로 두개의 컬럼을 묶은 복합 인덱스를 사용해야 한다

*tip 인덱스 작용하는 지 확인하기 위해서는 explain 명령어로 확인할 수 있다

데이터베이스 트래픽 분산

레플리케이션 : 마스터와 슬래이브 구조를 통해 분산

쓰기 작업은 마스터가 담당해야 하고 마스터는 확장하기 어렵다. 하지만 WEB 서비스 특성상 쓰는 것 보다 읽는 요청이 훨씬 많기 때문에 마스터에 병목현상이 생기는 경우는 별로 없다

TIP 만약 많은 쓰기 작업이 발생하는 경우 nosql을 사용하는 것도 고려할 것

대표적인 nosql

redis , inmemory db , key value

mongodb , document

elasticsearch, document

데이터 분산

파티셔닝과 샤딩 :

파티셔닝이란?

데이터를 다수의 엔티티로 나누는 데이터 분산이다. 수직 파티셔닝과 수평 파티셔닝 있다.

수직 파티셔닝

수직 파티셔닝은 테이블을 구조적으로 분리한다. 이렇게 분리하여 각기 다른 서버에 테이블이 존재할 경우 JOIN을 할 수 없다. 따라서 테이블을 분리할 때 연관 여부에 따라 분리할지 결정해야 한다.

수평 파티셔닝(샤딩과 동일)

*tip RDB에서 어플리케이션단에서 샤딩을 사용하는 방법

https://techblog.woowahan.com/2687/

파티셔닝의 단점

운용이 복잡해지고 고장률이 높아진다

이중화 구조를 생각했을 때 마스터 : 슬래이브 , 1:4 세트로 엮는 것이 좋음

*1대는 페일오버를 위한 예비용 서버

*이중화 구조를 이용한 무중단 배포 전략

출처 : https://deveun.tistory.com/entry/이중화-서버의-무중단-배포

Rolling 방식서버1(v1) 트래픽 차단 -> 서버1에 배포 -> 서버1(v2) 트래픽 오픈 -> 서버2(v1) 트래픽 차단 -> 서버2에 배포 -> 서버2(v2) 트래픽 오픈
Blue-Green기존 시스템과 동일한 환경으로 Stand-by 서버 그룹을 구성 -> Stand-by 서버 그룹을 v2로 업데이트 -> Stand-by 서버그룹(v2) 오픈 -> 신버전의 서버그룹으로 트래픽 전환 -> 기존 서버그룹(v1) Stand-by
CanaryBlue-green 방식처럼 구버전/신버전 서버 구성 -> 일부 트래픽을 신버전 서버로 라우팅 -> 오류발생 테스트 -> 신버전 서버로 순차적으로 트래픽 전환

알고리즘

대규모 데이터를 대상으로 한 경우, 실질적으로 실용성을 띄는 것은 O(nlogn) 부근 까지다. 그 이상되면 n에 대해 계산량이 급격하게 커지므로 계산이 끝나지 않는 경우가 있다

압축하는 알고리즘을 사용하면 cpu 사용률은 증가하지만 디스크 i/o의 처리량을 줄여서 전체적인 처리량을 올릴 수 있다