04. 분산을 고려한 MySQL 운용
11강. 인덱스를 올바르게 운용하기
- 분산을 고려한 MySQL 운용에는 세 가지 포인트가 있다.
OS 캐시활용, 인덱스, 확장 전제 설계가 있다.
OS 캐시 활용
- 전체 데이터 크기에 주의한다.
데이터량 < 물리 메모리를 유지해야 한다.
- 메모리가 부족할 경우엔 증설한다.
- 스키마 설계가 데이터 크기에 미치는 영향성을 고려한다.
- 이를 위해서는 정규화가 잘 되어야 한다.
- 정규화를 통해 용량을 크게 줄일 수 있으나, 경우에 따라서는 쿼리가 복잡해져 속도가 떨어지는 경우가 발생한다.
- 따라서 속도와 데이터 크기 간의
상반관계를 고려해야 한다.
인덱스의 중요성
- 인덱스 = 색인으로 추가적인 저장 공간을 활용하여 데이터베이스 테이블의 동작 속도를 높여주는 자료 구조이다.
- 이의 자료구조는 기본적으로
트리가 사용된다.
- MYSQL의 인덱스는 기본적으로
B+트리 데이터 구조를 갖는다.
- 외부 기억장치 탐색 시 Seek 횟수 최소화 → O(n) → O(log n)
- 이를 통해 일부 노드를 순회하는 것만으로 데이터에 도달하게 된다.
- 데이터가 적은 경우는 인덱스를 사용할 때 트리를 순회하는 오버헤드가 더 커서 선형탐색이 더 빠른 경우가 있다.
- MYSQL은 이 상황에선 사용하지 않는 최적화 작업을 해준다.
12강. MySQL의 분산
MySQL의 레플리케이션 기능
레플리케이션 마스터를 정하고 마스터를 뒤따르는 서버(slave)를 정해 두면 마스터에 쓴 내용을 슬레이브가 폴링해서 동일한 내용으로 자신을 갱신하는 기능- 슬레이브는 마스터의 replica가 된다.
- 따라서 ap 서버에서는 로드밸런서를 경유해 쿼리를 여러 서버로 분산한다.
- 이때 select 등의 참조 쿼리만 로드밸런서로 흘러가도록 하고, 갱신 쿼리는 마스터로 직접 던저야 한다.
- 갱신 쿼리를 슬레이브로 던지면 내용 동기화가 이루어지지 않는다.
- MySQL은 마스터와 슬레이브 간 내용 불일치를 감지하여 레플리케이션을 중지한다.
마스터/슬레이브의 특징
- 참조 계열 쿼리 확장 -> 메모리에 맞춘 서버 대수 증설
- 마스터는 확장 불가
- 갱신 계열 쿼리가 늘어나면 문제가 생김 ex) 발자국
- 마스터 부하는 테이블 분할이나 key-value 스토리지 등으로 확장
13강. MySQL의 스케일아웃과 파티셔닝
MySQL의 스케일아웃 전략
- 데이터가 메모리에 올라가면 메모리에 올리고, 아니라면 메모리 증설
- 메모리 증설이 불가능하다면
파티셔닝을 사용한다.
파티셔닝은 테이블을 서로 다른 서버에 놓아서 분할하는 방식인데, 이는 국소성을 활용해 분산하여 캐시가 유효해 속도 개선의 효과가 있다.파티셔닝을 전제로 한 설계가 필수로 동반되어야 하는데, 따라서 JOIN 쿼리는 신중하게 사용해야 한다.
- 대상 테이블을 앞으로도 분할하지 않을 것이라 보장할 때만 사용하는 것이 좋다.
파티셔닝의 상반관계
- 파티셔닝의 좋은 점은 부하가 내려가고 국소성이 늘어나 캐시 효과가 높아진다는 점이다.
- 하지만 아래와 같은 나쁜 점도 존재한다.
- 운용이 복잡해진다.
- 어디에 어떤 DB가 있는지 파악하는 게 힘들고, 장애에 민첩하게 대응하기 힘들다.
- 고장률이 높아진다.
- 따라서 파티셔닝은 어디까지나 마지막 카드가 되어야 한다.
다중화에 필요한 서버대수
- 무정지 복구를 위해 다중화를 고려하자면 서버 4대를 1세트라고 생각해야 한다.
