InnoDB 의 핵심 기능-캐 시 삽입,두 번 쓰기,자체 적응 hash 색인 상세 설명

InnoDB 메모리 엔진 의 관건 적 인 특성 은 버퍼 삽입,두 번 쓰기(double write),자체 적응 해시 색인(adaptive hash index)을 포함한다.이러한 특성 은 InnoDB 메모리 엔진 에 더 좋 은 성능 과 신뢰성 을 가 져 다 주 었 다.
삽입 버퍼
삽입 버퍼 는 InnoDB 메모리 엔진 의 핵심 특성 중 가장 설 렌 다.그러나 이 이름 은 버퍼 삽입 이 버퍼 의 일부분 이 라 고 생각 할 수 있다.그렇지 않 으 면 InnoDB 버퍼 에 Insert Buffer 정보 가 있 는 것 도 좋 지만 Insert Buffer 는 데이터 페이지 와 마찬가지 로 물리 페이지 의 구성 부분 이기 도 합 니 다.
홈 키 는 줄 의 유일한 식별 자 입 니 다.프로그램 에 기 록 된 삽입 순 서 는 홈 키 가 증가 하 는 순서에 따라 삽 입 됩 니 다.따라서 집합 색인 을 삽입 하 는 것 은 일반적으로 순서 이 며 디스크 의 무 작위 읽 기 가 필요 하지 않 습 니 다.
예 를 들 어 다음 SQL 에 정 의 된 표:create table t(id int autoincrement,name varchar(30),primary key(id));
id 열 은 자체 적 으로 증가 합 니 다.이것 은 삽입 작업 을 수행 할 때 id 열 이 자동 으로 증가 하고 페이지 의 줄 기록 은 id 실행 순서에 따라 저장 된다 는 것 을 의미 합 니 다.일반적으로 다른 페이지 의 실행 기록 을 무 작위 로 읽 을 필요 가 없습니다.따라서 이런 상황 에서 삽입 작업 은 일반적으로 빨리 완성 된다.단,표 마다 하나의 집합 색인 만 있 을 수 는 없습니다.더 많은 경우,표 에 여러 개의 비 집합 보조 색인(secondary index)이 있 습 니 다.예 를 들 어,우 리 는 name 이 필드 에 따라 찾 아야 하 며,name 이 필드 는 유일한 것 이 아 닙 니 다.
표 는 다음 과 같은 SQL 문 구 를 정의 합 니 다:create table t(id int autoincrement,name varchar(30)，primary key(id),key(name));
이런 상황 에서 비 집합 적 이 고 유일한 색인 이 아니다.삽입 작업 을 할 때 데이터 페이지 의 저장 은 홈 키 id 의 실행 순서에 따라 저장 되 지만 비 집합 색인 에 대해 잎 노드 의 삽입 은 더 이상 순서 가 아 닙 니 다.이 럴 때 는 비 집합 색인 페이지 를 이산 적 으로 방문 해 야 하 며,삽입 성능 이 여기 서 낮 아 집 니 다.그러나 이것 은 이 name 필드 의 색인 오류 가 아 닙 니 다.B+트 리 의 특성 이 비 집합 색인 삽입 의 이산 성 을 결정 하기 때 문 입 니 다.
InnoDB 메모리 엔진 은 삽입 버퍼 를 창의 적 으로 설 계 했 습 니 다.비 집합 색인 에 대한 삽입 이나 업데이트 작업 은 매번 색인 페이지 에 직접 삽입 하 는 것 이 아니 라 삽 입 된 비 집합 색인 페이지 가 버퍼 에 있 는 지 여 부 를 먼저 판단 합 니 다.있 으 면 바로 삽입 합 니 다.없 으 면 먼저 삽입 버퍼 에 넣 습 니 다.데이터베이스 라 는 비 집합 색인 이 잎 노드 에 꽂 혀 있 는 것 을 속 이 는 것 과 같 습 니 다.그 다음 에 일정한 주파수 로 삽입 버퍼 와 비 집합 색인 페이지 서브 노드 의 합병 작업 을 수행 합 니 다.이 때 는 보통 여러 개 를 하나의 작업 에 삽입 할 수 있 습 니 다(하나의 색인 페이지 에 있 기 때 문 입 니 다).이 는 비 집합 색인 에 대한 삽입 과 수정 작업 의 성능 을 크게 향상 시 켰 다.
버퍼 삽입 사용 은 다음 과 같은 두 가지 조건 을 만족 시 켜 야 합 니 다.
1.색인 은 보조 색인 이다.
2.색인 은 유일한 것 이 아니다.
상기 두 가지 조건 을 만족 시 킬 때 이 노 DB 메모리 엔진 은 삽입 버퍼 를 사용 하여 성능 을 향상 시 킬 수 있다.그러나 한 가지 상황 을 고려 하여 응용 프로그램 은 대량의 삽입 과 업데이트 작업 을 수행 합 니 다.이런 작업 은 유일한 비 집합 색인 과 관련 되 어 있 습 니 다.만약 에 이 과정 에서 데이터 베이스 가 지연 되면 대량의 삽입 버퍼 가 실제 비 집합 색인 에 통합 되 지 않 을 것 입 니 다.그렇다면 회복 에 오 랜 시간 이 걸 릴 수 있 고 극단 적 인 상황 에서 합병 복구 작업 을 수행 하 는 데 몇 시간 이 걸 릴 수도 있다.
보조 색인 은 유일한 것 이 아 닙 니 다.버퍼 에 삽입 할 때 색인 페이지 를 찾 지 않 기 때 문 입 니 다.찾 으 면 또 분 산 된 읽 기 가 있 을 것 이 고 버퍼 를 삽입 하면 의 미 를 잃 게 된다.
버퍼 삽입 정보 보기:
show engine innodb status\G

seg size 는 현재 삽입 버퍼 의 크기 를 2*16KB,free list len 은 남 은 목록 의 길 이 를,size 는 합 쳐 진 기록 페이지 의 수 를 나 타 냅 니 다.
다음 줄 은 성능 향상 을 보 여 주 었 기 때문에 우리 가 진정 으로 관심 을 가 지 는 것 일 것 이다.inserts 는 삽 입 된 기록 수 를 대표 하고 merged recs 는 합 친 페이지 의 수량 을 대표 하 며 merges 는 합 친 횟수 를 대표 합 니 다.
merged recs:merges 는 약 3 대 1 입 니 다.삽입 버퍼 는 비 집합 색인 페이지 의 IO 요청 을 약 3 배 낮 춥 니 다.
질문:
현재 버퍼 삽입 에 문제 가 있 습 니 다.쓰기 가 밀집 되 어 있 는 상황 에서 버퍼 를 삽입 하면 버퍼 메모 리 를 너무 많이 사용 합 니 다.기본 적 인 상황 에서 최대 1/2 의 버퍼 메모 리 를 사용 할 수 있 습 니 다.Percona 는 버퍼 가 너무 많은 버퍼 메모 리 를 사용 하 는 문 제 를 수정 하기 위해 패 치 를 발 표 했 습 니 다.구체 적 인 것 은 http:/www.percona.com/percona-lab.html 에서 찾 을 수 있 습 니 다.쉽게 말 하면 IBUF 수정POOL_SIZE_PER_MAX_SIZE 는 삽입 버퍼 의 크기 를 제어 할 수 있 습 니 다.예 를 들 어 IBUFPOOL_SIZE_PER_MAX_SIZE 를 3 으로 바 꾸 면 최대 1/3 의 버퍼 메모리 만 사용 할 수 있 습 니 다.
두 번 쓰다
버퍼 삽입 이 InnoDB 메모리 엔진 에 성능 을 가 져 다 준다 면,두 번 의 쓰기 가 InnoDB 메모리 엔진 에 가 져 다 주 는 것 은 데이터 의 신뢰성 이다.데이터 베 이 스 를 지연 시 킬 때 데이터 베 이 스 는 한 페이지 를 쓰 고 있 을 수 있 습 니 다.이 페이지 는 일부분(예 를 들 어 16K 페이지,앞의 4K 페이지 만 쓰 는 것)만 쓰 여 있 는 상황 이 발생 할 수 있 습 니 다.우 리 는 부분 적 인 쓰기 실효(parial page write)라 고 부 릅 니 다.이 노 DB 메모리 엔진 이 더 블 릿 기술 을 사용 하지 않 기 전 일부 쓰기 가 효력 을 상실 해 데이터 가 분실 되 는 경우 가 있 었 다.
쓰기 가 효력 을 잃 으 면 로 그 를 다시 만들어 복구 할 수 있다 는 생각 이 들 수도 있다.이것 은 방법 이다.그러나 분명 한 것 은 로그 에 기 록 된 것 은 페이지 에 대한 물리 적 조작 입 니 다.예 를 들 어 오프셋 800,'aaaa'기록 을 쓰 는 것 입 니 다.만약 이 페이지 자체 가 이미 손상 되 었 다 면,다시 그것 을 다시 하 는 것 은 무의미 하 다.응용(apply)로 그 를 다시 만 들 기 전에 한 페이지 의 사본 이 필요 합 니 다.실효 가 발생 했 을 때 페이지 의 사본 을 통 해 이 페이지 를 복원 하고 다시 만 드 는 것 이 doublewrite 입 니 다.
InnoDB 저장 엔진 doublewrite 의 시스템 구 조 는 그림 2-4 참조

doublewrite 는 두 부분 으로 구성 되 어 있 습 니 다.일 부 는 메모리 에 있 는 doublewrite buffer 이 고 크기 는 2MB 입 니 다.다른 부분 은 물리 디스크 에 있 는 공유 표 공간 에서 연속 되 는 128 페이지,즉 두 개의 구역(extent)으로 크기 가 똑 같이 2MB(페이지 의 사본)이다.버퍼 의 더러 운 페이지 를 새로 고 칠 때 디스크 를 직접 쓰 지 않 고 memcpy 함 수 를 통 해 더러 운 페이지 를 메모리 에 있 는 doublewrite buffer 로 복사 한 다음 doublewrite buffer 를 통 해 두 번 더 나 누 어 공유 표 공간의 물리 디스크 에 1MB 를 기록 한 다음 에 fsync 함 수 를 즉시 호출 하여 버퍼 쓰기 에 문제 가 생기 지 않도록 디스크 를 동기 화 합 니 다.이 과정 에서 doublewrite 페이지 는 연속 적 이기 때문에 이 과정 은 순서대로 쓰 여 져 비용 이 그리 많 지 않다.doublewrite 페이지 의 기록 을 마 친 후 doublewrite buffer 의 페이지 를 각 표 공간 파일 에 기록 합 니 다.이 때 기록 은 분 산 됩 니 다.
다음 명령 을 통 해 doublewrite 가 실행 되 는 상황 을 관찰 할 수 있 습 니 다. show global status like 'innodb_dblwr%'\G

doublewrite 는 모두 18 445 페이지 를 썼 지만 실제 기록 횟수 는 434 이다.(42:1)  기본적으로 64 대 1 에 부합 한다.
당신 의 시스템 이 러시아워 에 있 는 것 을 발견 하면 Innodbdblwr_pages_written:Innodb_dblwr_writes 는 64 대 1 보다 훨씬 작 습 니 다.시스템 기록 압력 이 그리 높 지 않다 는 것 을 말 해 줍 니 다.
운영 체제 가 페이지 를 디스크 에 기록 하 는 과정 에서 무 너 지면 복구 과정 에서 InnoDB 저장 엔진 은 공유 표 공간의 doublewrite 에서 페이지 를 바 꾸 는 복사 본 을 찾 아 표 공간 파일 로 복사 한 다음 로 그 를 다시 만 들 수 있 습 니 다.doublewrite 에서 복구 되 는 상황 을 보 여 줍 니 다. 

090924 11：36：32 mysqld restarted
090924 11：36：33 InnoDB：Database was not shut down normally！
InnoDB：Starting crash recovery.
InnoDB：Reading tablespace information from the.ibd files……
InnoDB：Error：space id in fsp header 0，but in the page header 4294967295
InnoDB：Error：tablespace id 4294967295 in file./test/t.ibd is not sensible
InnoDB：Error：tablespace id 0 in file./test/t2.ibd is not sensible
090924 11：36：33 InnoDB：Operating system error number 40 in a file operation.
InnoDB：Error number 40 means'Too many levels of symbolic links'.
InnoDB：Some operating system error numbers are described at
InnoDB：http：//dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html
InnoDB：File name./now/member
InnoDB：File operation call：'stat'.
InnoDB：Error：os_file_readdir_next_file（）returned-1 in
InnoDB：directory./now
InnoDB：Crash recovery may have failed for some.ibd files！
InnoDB：Restoring possible half-written data pages from the doublewrite
InnoDB：buffer……

파라미터 skipinnodb_doublewrite 는 두 번 의 쓰기 기능 을 금지 할 수 있 습 니 다.이 때 앞에서 언급 한 쓰기 실효 문제 가 발생 할 수 있 습 니 다.단,서버(slave server)에서 여러 대가 있다 면 빠 른 성능(예 를 들 어 slave 에서 하 는 것 은 RAID 0)을 제공 해 야 합 니 다.이 인 자 를 사용 하 는 것 이 방법 일 수도 있 습 니 다.그러나 데이터 의 신뢰성 이 높 은 메 인 서버(master server)를 제공 해 야 할 때 는 언제든지 두 번 의 쓰기 기능 을 켜 야 합 니 다.
주의:일부 파일 시스템 자체 가 ZFS 파일 시스템 과 같은 일부 실효 방지 체 제 를 제공 합 니 다.이런 상황 에서 우 리 는 doublewrite 를 사용 하지 않 을 것 이다. 
자동 적응 해시 인덱스
해시(hash)는 매우 빠 른 검색 방법 으로 일반적인 상황 에서 찾 는 시간 복잡 도 는 O(1)이다.SQL Server 와 Oracle 의 해시 연결(hash join)과 같은 연결(join)작업 에 자주 사 용 됩 니 다.그러나 SQL Server 와 Oracle 등 흔히 볼 수 있 는 데이터 베 이 스 는 해시 색인(hash index)을 지원 하지 않 습 니 다.MySQL 의 Heap 저장 엔진 의 기본 색인 유형 은 해시 이 고,InnoDB 저장 엔진 은 해시 색인(adaptive hash index)에 적응 하 는 또 다른 실현 방법 을 제시 했다.
InnoDB 메모리 엔진 은 테이블 에 있 는 인덱스 찾기 를 모니터링 하고,해시 인덱스 를 만 드 는 것 이 속도 향상 을 가 져 올 수 있 음 을 관찰 하면 해시 인덱스 를 만 들 기 때문에 자체 적응(adaptive)이 라 고 부른다.해시 색인 은 버퍼 의 B+트 리 구 조 를 통 해 만들어 지기 때문에 구축 속도 가 빠르다.또한 표 전 체 를 해시 색인 으로 만 들 필요 가 없습니다.InnoDB 저장 엔진 은 방문 빈도 와 패턴 에 따라 일부 페이지 에 해시 색인 을 자동 으로 만 듭 니 다.
InnoDB 의 공식 문서 에 따 르 면 해시 색인 에 적응 하 는 것 을 사용 하면 읽 기와 쓰기 속 도 를 2 배 높 일 수 있 습 니 다.보조 색인 연결 작업 에 있어 서 성능 이 5 배 향상 된다.자체 적응 해시 색인 은 매우 좋 은 최적화 모델 로 그 디자인 사상 은 데이터 베이스 자체 최적화(self-tuning)이다.즉,DBA 가 데이터 베 이 스 를 조정 할 필요 가 없다.
현재 해시 색인 에 적응 하 는 사용 현황 보기:show engine innodb status\G


이 제 는 해시 색인 에 적응 하 는 사용 정 보 를 볼 수 있 습 니 다.해시 색인 에 적응 하 는 크기,사용 상황,초당 해시 색인 검색 에 적응 하 는 상황 을 포함 합 니 다.주의해 야 할 것 은 해시 색인 은 같은 값 의 검색 에 만 사용 할 수 있 습 니 다.예 를 들 어 select*from table where indexcol='xxx',범위 찾기 와 같은 다른 검색 유형 은 사용 할 수 없습니다.그래서 여기 에는 non-hash searches/s 의 상황 이 나 타 났 다.hash searches:non-hash searches 명령 으로 해시 색인 을 사용 한 후의 효율 을 대충 알 수 있 습 니 다.
자체 적응 해시 색인 은 InnoDB 저장 엔진 에 의 해 제어 되 기 때문에 이곳 의 정 보 는 우리 가 참고 할 수 있 습 니 다.하지만 우 리 는 인자 innodb 를 통 해adaptive_hash_index 에서 이 기능 을 사용 하지 않 거나 시작 합 니 다.기본적으로 시작 합 니 다.
이상 의 이 InnoDB 의 관건 적 인 특성 은 캐 시 삽입,두 번 쓰기 입 니 다.hash 색인 에 적응 하 는 상세 한 설명 은 바로 작은 편집 이 여러분 에 게 공유 하 는 모든 내용 입 니 다.참고 하 시기 바 랍 니 다.여러분 들 도 많이 응원 해 주시 기 바 랍 니 다.