Review1. 4_아키텍처(4.1, 4.2)

[DaehunGwak]

진도

4.1 MySQL 엔진 아키텍처 4.2 InnoDB 스토리지 엔진 아키텍처

일시

• 2022.06.12.(일) 21:00

[Edwin222]

4-1챕터

MySQL 서버 구조

• 세션 스레드

  • 인메모리 작업 (버퍼 or 캐시 리드 라이트)
  • 메모리 << 디스크(리드)

• 백그라운드 스레드

  • 디스크 >> 메모리
  • 쓰기 지연은 OK이므로 백그라운드에서 버퍼링 처리

• 로컬 메모리 : 세션 스레드에서 한 커넥션의 라이프 사이클 이내에 쓸만한 것이면 전부 여기.

• 글로벌 메모리 : 테이블처럼 모든 세션에서 같이 보고자 하는 공유 자원이 여기.

쿼리 구조

• 파싱 -> 옵티마이징 -> 실행(하면서 스토리지 엔진 접근)

4-2챕터

MVCC (Multi Version Concurrency Control)

1. Undo Log를 통해 여러버전의 데이터를 접근할 수 있도록 유지하고
2. 트랜잭션의 처리 상황에 따라 특정한 버전의 데이터를 읽을 수 있게 하여
3. 잠금 없이 일관성있는 읽기를 제공한다.

잠금 없이 일관성을 유지하며 읽기 : 데이터를 변경하지 않는 SELECT가 잠금을 걸지 않는 원리.

• READ UNCOMMITED인 경우 커밋되지 않았어도 변경된 데이터를 메모리나 디스크로부터 읽어서 반환 (커밋 전에도 데이터 변경을 선반영하고, 언두로그를 남긴다)
• READ COMMITED인 경우, 커밋되기 전이라면 언두로그를 참조해서 변경 전의 데이터를 반환

언두 로그??

• 트랜잭션 롤백을 보장하고 보호 수준에 따른 적절한 격리 수준을 보장해주기 위한, 변경된 데이터의 과거 버전에 해당하는 것을 보존하는 로그.

• 회수 타이밍

  • 자동 모드: 트랜잭션이 커밋되면 더이상 과거 내역을 보존할 필요가 없으므로, 주기적으로 그러한 언두 로그를 확인해서 자동 삭제한다.
  • 수동 모드: 직접 언두 로그가 저장된 테이블 스페이스를 비활성화하면 테이블 스페이스를 반납. 테이블 스페이스가 3개는 넘어야 동작한다.

버퍼 풀

기본 데이터 구조

• 사용중인 페이지를 리스트 형태로 관리.

• 자주 접근하는 페이지일수록 리스트의 머리로 가게 되므로 자연스럽게 안 쓰는 페이지는 뒤로 밀린다.

• 새롭게 접근하는 페이지는 5/8지점에 추가한다. 새로 접근하는 페이지도 마찬가지로 자주 접근할수록 앞으로 가게 됨.

• 사용중인 페이지에 대한 리스트(LRU)는 온디맨드 플러시

  • 플러시할때 끝에서부터(제일 늙은거) 몇개까지 스캔할거냐를 환경설정으로 지정 가능.

• 어댑티브 해시 인덱스

  • LRU 헤드쪽 데이터에 대해 자동으로 생성하는 인덱스.

  • B 트리가 아니라 해시 테이블로 동작한다. B 트리 검색에 걸리는 시간을 단축하기 위해 사용함.

  • 유리할 때

  • Equal 검색이 많거나 일부 데이터만 조회하는 경우에는 성능 향상에 큰 도움이 된다. (해시 테이블 특성상)

  • 메모리 IO가 잦을수록 유리하다. (어댑티스 해시 인덱스는 메모리에 해당하는, 버퍼풀에 접근할때만 사용되므로)

  • 불리할 때

  • 레인지 스캔 자주 하거나 다량의 데이터를 한번에 읽는 경우엔 무쓸모.(해시 테이블 특성상)

  • 디스크 IO가 잦으면 무쓸모. (버퍼 풀에 자주 접근해야 성능 이득이 있다.)

  • 쓸모 없는 경우에는 안 쓰는게 낫다. 해시 테이블도 엄연히 메모리의 한 구석을 차지하므로.

리두 로그 계산 이번엔 이해했다.

• 리두 로그 : 더티 페이지는 1:1 대응.

  • 리두 로그가 없으면 더티 페이지의 뭐가 더티인지 알 수 없으므로, 더티 페이지의 데이터 반영 전까지는 무조건 대응되는 활성 상태의 리두 로그가 존재한다.

• 고로 리두 로그 공간 * (더티 페이지 크기 / 리두 로그 엔트리 크기) 만큼의 용량을 버퍼 풀에서 더티 페이지 처리로 쓸 수 있다는 것.

• 다시 보는 예제 (로그 엔트리 4KB, 페이지 사이즈 16KB라고 가정)

  • 버퍼풀 100GB / 리두로그 100MB

  • 더티 페이지 400MB까지 사용 가능

  • 99.6GB가량은 클린페이지로만 쓸 수 있는 상태

  • DML 사용시 고확률로 상당한 병목이 발생할 것이기에 좋지 않다.

  • 버퍼풀 100MB / 리두로그 100GB

  • 리두 로그는 400GB까지 쓸 수 있으나 버퍼풀이 100MB고 리두 로그도 결국 버퍼 풀을 쓰므로 무의미한 수치다.

  • 버퍼풀 전체에 리두 로그를 담을 수 있다는 것이니 이론상으로는 4:1 비율로 쪼개서 최대 80MB의 더티 페이지와 20MB의 리두 로그를 쓸 수 있음.

    • 편집하지 않은 클린 페이지가 몇 개 더 올라가있다면 더 줄어들 것.

  • 다루는 데이터의 크기에 따라 살아남을 수는 있겠지만 애초에 리두로그 100GB를 하는 것 자체가 무의미하여 좋지 않다.

디스크 플러시

• 주기적으로 버퍼 풀에서 더티페이지를 플러시 (타이밍은 용량 환경 설정값 변경 가능)
  • 더티 비율이 90% 이상 올라가면 자동으로 플러시하지만 디스크 IO가 폭발할 가능성이 높으므로 그 전에 점진적으로 수행할 수 있도록 하자.

[DaehunGwak]

4.1 MySQL 엔진 아키텍처

• 커뮤니티는 커넥션당 스레드, 엔터프라이즈/Percona 는 스레드 풀 활용
• 글로벌 메모리(공유해서 사용할꺼~), 로컬 메모리(세션메모리, 커넥션당 처리 담당할꺼~)
• 플러그인 모델 사용
  • 플러그인 대체 컴포넌트 사용~
• 실행 구조
  • 쿼리 파서 → 전처리기 → 옵티마이저 → 쿼리 실행기 → (핸들러를 통해) 스토리지 엔진에게 포워딩
• 쿼리 캐시는 제거~

4.2 InnoDB 스토리지 엔진 아키텍처

• 프라이머리 키에 의한 클러스터링으로 저장 (InnoDB) → 레인지 스캔 이점
• MVCC (Multi Version Concurrency Control)
  • 처리 순서
    • 업데이트 시 버퍼풀에 있던 내용을 변경 전 내용 만 언두로그에 포워딩
    • 버퍼풀 내용 업데이트
    • 백그라운드 스레드를 통해 데이터 파일에 업데이트
    • 언두영역 백업 분이 필요 없을 시 삭제 (커밋 되었다거나, 롤백되었다거나, 너무 오래되서 해당 쿼리는 더 이상 실행 되지 않아야 될때를 백그라운드가 판단한다거나)
  • 업데이트 쿼리 처리중 리드 시
    • READ_UNCOMMITED 시
      • 그냥 버퍼풀 내용 끄집어냄
    • READ_COMMITED 시
      • 버퍼풀 + 언두로그 취합
  • 이에 따라 잠금 없는 일관된 읽기 (non-locking consistent read) 를 지원
• 자동 데드락 감지
  • innodb_lock_wait_timeout 으로 데드락 판단 가능
• InnoDB 버퍼풀
  • 데이터 파일, 인덱스 정보 캐싱 공간
  • 쓰기작업 지연 처리를 위한 버퍼 역할
  • 플러시
    • 플러시 리스트에서 더티 페이지 중 가장 오래된것 디스크에 반영
• Double Write Buffer
  • 더티 페이지 플러시할 시, 반영할 더티페이지를 기록하는 영역 (시스템 테이블스페이스)
  • 각 페이지마다 반영유무를 기록하여 시스템 폴트를 대비
• 언두 로그
  • 트랜잭션 보장
  • 격리 수준 보장
• 체인지 버퍼
  • 변경해야될 인덱스 페이지가 버퍼풀에 없을 때 디스크로 부터 읽어와서 잠시 저장하는 영역
  • 체인지 버퍼 머지 스레드를 통해 처리
• 리두 로그 및 로그 버퍼
  • ACID 의 Durable (영속성)
  • 디비 서버 비정상 종료시 데이터 파일에 기록하지 못한 데이터를 잃지 않게 해주는 장치
  • 변경 내용은 리두 로그로 먼저 기록
  • 로그 버퍼를 같이활용
• 어댑티브 해시 인덱스
  • InnoDB 스토리지 엔진에서 자주 쓰는 데이터에 대해 자동으로 생성하는 인덱스
  • B-Tree 검색 시간 줄여주기 위해 도입
  • 도움 되는 경우
    • 디스크 데이터가 버퍼풀 크기와 비슷해서 디스크 읽기가 많지 않은 경우
    • 동등 조건 검색
    • 데이터 중 일부 데이터만 집중되어 검색될 경우

[minkukjo]

4.1

• 포그라운드 쓰레드 : 클라이언트의 쿼리 요청을 처리하는 쓰레드
• 백그라운드 쓰레드 : 로그를 디스크에 기록하거나, 인서트 버퍼를 병합하거나, InnoDB 버퍼풀 데이터를 디스크에 기록하거나, 데이터를 버퍼로 읽어오거나, 잠금 또는 데드락을 모니터링 하거나 하는 행위들을 담당하는 쓰레드
• 대부분의 상용 DBMS는 읽기 작업의 경우 즉시 처리하지만, 쓰기 작업의 경우 버퍼링해서 일괄 처리하는 기능으로 탑재되어있다. 쓰기 버퍼링의 경우 버퍼풀에 데이터를 반영하고 주기적으로 디스크로 write 시킨다.
• 8버전에서는 쿼리캐시 없음

4.2

• MVCC는 잠금을 사용하지 않으면서 일관된 읽기를 제공하는 기능이다.
• 언두로그를 사용해 변경전 값을 복사해두고 필요에 따라서 복구를 하거나 트랜잭션 경합 상태일 때에 처리를 담당한다.
• 결국 잠금을 사용하지 않는 읽기는, 트랜잭션이 경합 상태일 때도, 다른 트랜잭션의 종료를 기다리지 않고 언두로그를 활용해 즉시 결과를 응답하는 모델을 의미한다.
• 언두로그 VS 리두로그
  • 묘하게 헷갈리는 두 친구들
  • 언두로그 : 잠금 없는 읽기를 위해 업데이트 이전 데이터를 보관하는 용도로 사용되는 로그, 트랜잭션의 보장과 격리 수준을 보장하기 위해 사용된다.
  • 리두로그 : 리두로그는 재사용 불가능한 공간을 표시하기 위한 로그. 더티 페이지가 버퍼풀에 무한정 머무를 수 없기 때문에 계속해서 로그 파일에 기록한 로그 엔트리가 새로운 로그 엔트리로 덮어씌워지게 된다. 이 때 재사용 불가능한 공간을 활성 리두 로그라고 부르며, 이 활성 리두 로그의 경우 덮어씌워질 수 없다.