대규모 서비스 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