4장 아키텍처

[qkrqudcks7]

04. 아키텍처

MVCC( Multi Version Concurrency Control )

• 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능.
• 하나의 레코드에 여러 버전이 동시에 관리된다.
• MVCC의 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하는 데 있다.

1. UPDATE 요청이 들어온다.
2. 디스크의 데이터 파일에는 변경 전 내용이 저장된다.
3. UPDATE 문이 실행되면 커밋 여부와 관계없이 InnoDB 버퍼 풀에는 새로운 값이 들어온다.
4. 변경 전 값만 언두 로그에 복사된다.

commit 이나 rollback이 안 된 상태에서 조회하면 어떤 값을 읽을까?

READ_UNCOMMITED

• InnoDB 버퍼 풀이 갖고 있는 변경된 데이터를 읽어서 반환한다.

READ_COMMITTED 이상인 경우

• 아직 커밋되지 않았기 때문에 언두 영역의 데이터를 반환한다.

InnoDB 버퍼 풀과 리두로그

clean page : InnoDB의 버퍼 풀은 디스크에서 읽은 상태로 전혀 변경되지 않은 페이지이다.
dirty page : insert, update, delete 명령으로 변경된 데이터를 가진 페이지이다.
LSN : log sequence number
checkpoint age : 활성 리두 로그 공간의 크기

InnoDB의 버퍼 풀은 서버의 메모리가 허용하는 만큼 크게 설정하면 할수록 쿼리의 성능이 빨라진다.

그러나 메모리 공간만 단순히 늘리는 것은 데이터 캐시 기능만 향상시키는 것이다. 버퍼 풀의 쓰기 버퍼링 기능까지 향상 시키라면?

• dirty page는 언젠가 디스크에 기록되어야 한다. 버퍼 풀에 무한정 머무를 수 없다.

• InnoDB 스토리지 엔진에서 리두 로그는 1개 이상의 고정 크기 파일을 연결해서 순환 고리처럼 사용한다.

• 즉 데이터 변경이 일어나면 리두 로그 파일에 기록된 로그 엔트리는 다시 새 엔트리로 덮어 쓰인다.

• 전체 리두 로그 파일에서 재사용 가능한 공간, 당장 불가능한 공간이 나뉘는데 불가능한 공간이 활성 리두 로그이다(화살표 가진 엔트리)

• 리두 로그 파일의 공간이 재사용될 수록 로그 포지션은 계속 증가된 값(LSN)을 가진다.

• InnoDB 스토리지 엔진은 주기적으로 체크포인트 이벤트를 발생시켜 리두 로그와 버퍼 풀의 dirty page를 디스크로 동기화 시킨다.

• 발생한 체크포인트 중 가장 최근 지점의 LSN이 활성 리두 로그 공간의 시작점이 된다.

• 그러나 활성 리두 로그 공간의 마지막은 계속해서 증가하기 때문에 체크포인트와 무관하다.

• 그리고 가장 최근 체크포인트의 LSN과 마지막 리두 로그 엔트리 LSN의 차이를 checkpoint age라고 한다.

따라서

• InnoDB 버퍼 풀의 더티 페이지는 특정 리두 로그 엔트리와 관계를 가진다.
• 체크포인트가 발생하면 체크포인트 LSN 보다 작은 리두 로그 엔트리와 관련된 더티 페이지, 리두 로그 엔트리는 모두 디스크로 동기화 된다.

Q. InnoDB 버퍼 풀이 100GB, 리두 로그 파일의 전체 크기가 100MB인 경우

• 리두 로그 파일 크기가 100MB가 최대이므로, checkpoint age 또한 최대 100MB이다.
• 평균 리두 로그 엔트리가 4KB면 100MB/4KB 인 25600개 dirty page만 버퍼 풀에 보관할 수 있다.
• 각 dirty page가 16KB라고 하면 허용 가능한 전체 dirty page는 400MB 밖에 안 된다.
• 따라서 버퍼 풀의 크기만 크고 실제 버퍼링 효과는 못보게 된다.

Q. InnoDB 버퍼 풀이 100MB, 리두 로그 파일의 전체 크기가 100GB인 경우

• 400GB 정도의 dirty page를 가질 수 있다.
• 하지만 버퍼 풀 크기가 100MB이므로, dirty page 크기 또한 100MB가 최대이다.

버퍼풀 크기 100GB면 리두 로그 파일은 5~10GB 수준이 적정

어댑티브 해시 인덱스

인덱스: 테이블에서 사용자가 설정한 B-Tree 인덱스

• 사용자가 수동으로 설정하는 것이 아닌, InnoDB 스토리지 엔진에서 사용자가 자주 요청하는 데이터에 대해 자동으로 생성하는 인덱스
• B-Tree 의 검색 시간을 줄여주기 위해 도입된 기능

B- tree , Adaptive Hash Index

B-tree

• 데이터는 Primary Key 순으로 정렬되어 관리되고, Secondrary Key는 인덱스키+PK를 조합으로 정렬이 됨
• 특정 데이터를 찾기 위해서는 Secondrary Key에서 PK를 찾고, 그 PK를 통해 다시 원하는 데이터로 찾아가는 형태
• 자주 사용되는 데이터 탐색에도 매번 트리의 경로를 쫓아가야 한다는 단점이 있다.

Adaptive Hash Index

• 인덱스 키 값 - 인덱스 키 값이 저장된 데이터 페이지의 주소의 쌍으로 관리된다.(b-tree 인덱스 고유번호, b-tree 인덱스 실제 키 값)
• 자주 사용되는 컬럼을 hash로 정의하여, B-Tree 를 타지 않고 바로 데이터에 접근할 수 있는 기능
• 자주 사용되는 데이터 값만 내부적으로 판단하여 상황에 맞게 hash 값을 생성한다.

cpu 사용량

• Adaptive Hash Index를 사용하지 않는 경우 CPU가 100% 였으나, Adaptive Hash Index를 사용한 이후에는 60% 정도

처리량

• 쿼리 응답 시간도 줄었기에 처리량 또한 늘어난 모습

주의사항

• 오래된 테이블인 경우에도 hash가 여전히 메모리에 남아있을 수 있으며, 이에 대한 제어는 불가능하다.
• 디스크 읽기가 많은 경우,
• 특정 패턴 쿼리가 많은 경우(join, like),
• 매우 큰 데이터를 가진 테이블을 폭 넓게 읽는 경우는 도움 안 됨

[ruthetum]

InnoDB가 주로 많이 사용되는 스토리지 엔진이지만 다른 스토리지 엔진도 같이 확인해보면 좋을 것 같아서 같이 보면 좋을 포스트 공유드려요.
책에도 MyISAM까지는 간단히 설명되어 있는데, Memory 엔진(혹은 TempTable)도 인지하고 있으면 좋을 것 같아요.

• storage 엔진 관련 공식 문서: https://dev.mysql.com/doc/refman/8.0/en/storage-engines.html

• 엔진 설명 포스트 1: https://nomadlee.com/mysql-%EC%8A%A4%ED%86%A0%EB%A6%AC%EC%A7%80-%EC%97%94%EC%A7%84-%EC%A2%85%EB%A5%98-%EB%B0%8F-%ED%8A%B9%EC%A7%95/

• 엔진 설명 포스트 2: http://asuraiv.blogspot.com/2017/07/mysql-storage-engine.html