초록 ▼

핵심개발기술 및 개발내용
MySQL InnoDB는 모든 테이블을 B-tree 인덱스 형태로 저장하고 테이블에 접근할 때에도 Primary key를 이용한다. 따라서 대부분의 스캔은 순차적 I./O (Sequential I/O)를 발생시키고 저장장치 종류에 상관없이 짧은 지연시간(Latency)를 보장할 수 있다. 이에 반해, secondary 인덱스를 이용한 인덱스 스캔을 할 경우, 하드디스크 (Harddisk) 저장장치 환경에서는 플래시 SSD 저장장치 환경에서보다 짧은 지연시간을 보장할 수 없다. 이는 Secondary 인

핵심개발기술 및 개발내용
MySQL InnoDB는 모든 테이블을 B-tree 인덱스 형태로 저장하고 테이블에 접근할 때에도 Primary key를 이용한다. 따라서 대부분의 스캔은 순차적 I./O (Sequential I/O)를 발생시키고 저장장치 종류에 상관없이 짧은 지연시간(Latency)를 보장할 수 있다. 이에 반해, secondary 인덱스를 이용한 인덱스 스캔을 할 경우, 하드디스크 (Harddisk) 저장장치 환경에서는 플래시 SSD 저장장치 환경에서보다 짧은 지연시간을 보장할 수 없다. 이는 Secondary 인덱스가 비군집 인덱스(Non-clustered index)이고, Secondary 인덱스를 이용한 스캔은 랜덤 I/O (Random I/O)를 유발하기 때문이다. 하지만 플래시 환경에서 Secondary 인덱스를 이용한 인덱스 스캔 성능 실험을 수행한 결과, 실험을 진행하는 동안의 총 CPU 활용률 25% 중 I/O wait 비율이 약 22%로 사용되고 있는 CPU의 80%가 I/O 처리를 기다리고 있음을 확인하였다.

또한, 플래시 SSD는 하드디스크와 다른 특성(예: 읽기 및 쓰기 성능비대칭성) 을 가지고 있기 때문에 SSD 특성을 이해하고 이러한 특성을 충분히 활용할 수 있는 새로운 DBMS 설계가 필요하다. 예를 들어, MySQL InnoDB 엔진의 데이터 페이지 기본 크기가 16KB로 하드 디스크의 입출력 지연시간을 줄이기 위해 비교적 큰 데이터 페이지 크기를 채택하였지만, 플래시 SSD의 최소 입출력 단위인, 4KB로 데이터 페이지 크기를 설정하는 것이 플래시 SSD 환경에서 DBMS 성능에 더 유리하다. 또한, 플래시 SSD 구조적 특성으로 여러 입출력을 병렬적으로 처리할 수 있고, 이를 Flash SSD의 내부 병렬성이라고 한다. 하지만 대부분의 DBMS의 인덱스 스캔은 동기적 입출력(Synchronous I/O)을 사용하기 때문에 단일 쿼리만 수행 될 경우, 한 페이지를 읽기 위해 한 칩(Chip)만 활성 되므로 플래시 SSD의 내부 병렬성을 충분히 활용하지 못한다.

그림 3은 MySQL InnoDB 인덱스 스캔 알고리즘의 의사 코드이다. MySQL InnoDB는 테이블을 Primary key에 대한 B-tree 형태로 저장을 하고 기본적으로 Primary key를 이용한 인덱스 스캔을 사용한다. 쿼리에 따라 Secondary 인덱스를 이용한 인덱스 스캔을 할 경우에는 Secondary 인덱스를 탐색하여 Secondary 인덱스 레코드를 획득한 후, 해당 레코드에서 Primary key 값을 추출한다. 추출한 값으로 Primary 인덱스를 탐색하여 데이터 레코드를 획득한다. Primary 인덱스를 이용하여 데이터에 접근할 경우, 접근 패턴이 순차적이기 때문에 짧은 지연시간을 기대할 수 있다. 하지만 Secondary 인덱스를 이용할 경우, Secondary 인덱스 레코드에서 추출한 Primary key 값들이 무작위적이므로 실제 데이터 페이지를 읽기 위한 접근 패턴도 무작위적이다. 따라서 Secondary 인덱스를 이용하여 데이터에 접근할 때에는 짧은 지연시간을 기대하기 어렵다.

본 연구에서는 오픈소스 데이터베이스 시스템인 MySQL InnoDB 엔진의 Secondary Index Scan 성능 향상을 위한 Prefetch 기능 구현하였다. Prefetch 구현 기법은 그림 4와 같다. Prefetch 구현은 InnoDB 인덱스 스캔 알고리즘 (그림3)에서 1-8행과 9행 사이에 추가되었으며, 플래그를 통해 활성화 또는 비활성화를 할 수 있다. Secondary 인덱스를 우선 탐색하여 Primary key 값을 우선 추출한다. 수집된 Primary key 값으로 Primary 인덱스의 level-1까지 탐색한 후, level-1의 노드에서 다음으로 접근할 자식 노드의 데이터 페이지 정보를 수집한다. 수집된 데이터 페이지 정보를 정렬한 후, 정렬된 데이터 페이지 정보를 이용하여 Prefetch를 수행한다. Prefetch 단위에 따라 수집할 데이터 페이지 개수가 달라진다. 예를 들어, Prefetch 단위가 8인 경우, 데이터 페이지도 8개까지 수집한 후 Prefetch를 요청한다. 본 기법은 곧 접근될 데이터 페이지를 미리 읽기 때문에 InnoDB 엔진의 버퍼 풀을 효율적으로 사용할 수 있다. 또한, 다수의 읽기를 동시에 요청하기 때문에 SSD의 내부 병렬성을 충분히 활용하여 읽기 대역폭(Bandwidth)를 향상시킬 수 있다.

성과
국내 저널 1건 게재, 국제 컨퍼런스 준비 중

파급 효과
그림 3과 그림4는 기존의 InnoDB 엔진과 Prefetch 기법이 구현된 InnoDB 엔진의 쿼리 수행 시간을 비교한 그래프이다. Prefetch 단위를 증가시키며 성능을 분석하였다. Single user의 경우, 기존의 InnoDB엔진보다 10배의 성능향상이 있었으며(그림 5), Multiple user의 경우, 기존의 InnoDB엔진보다 치소 1.5배, 최대 4배까지 성능 향상을 보였다(그림 6). Prefetch 단위를 증가시킬수록, 병렬적으로 처리할 수 있는 입출력의 양이 증가한다. 따라서 저장장치의 내부 병렬성을 더욱 효과적으로 활용할 수 있으므로 DBMS의 성능향상으로 이어진다. 하지만, SSD 내부 병렬성과 입출력 대기열 크기에 한계가 있기 때문에 Prefetch 단위를 계속 증가하더라도 성능향상은 특정 값에 수렴한다.
본 기법은 MySQL InnoDB 엔진의 Secondary Index 스캔 기법 향상을 위해 Libaio 라이브러리를 활용하여 간단한 코드 수정으로 성능 향상을 보였다. 또한, 데이터페이지 크기와 Prefetch 단위의 상관관계를 파악하여 최적화할 수 있는 방법을 확인하였다. 서버 변수를 추가하여, 쉽게 Prefetch 기능을 활성화하여 쓸 수 있도록 하였으며, 매뉴얼도 작성하였다.

공개SW 확산 노력
• SWRC FlashSQL 깃허브(Github) 업로드 및 저장소 관리(https://github.com/FlashSQL/mysql-with-aio-prefetch)
• SWRC FlashSQL 홈페이지 기술 블로그 업로드(http://flashsql.skku.ac.kr/?p=1563)
• 특히 SWRC FlashSQL 홈페이지의 경우, 본 기법에 대한 논문을 게재하였고, 다운로드 받을 수 있도록 하였음
• 또한 Github 저장소를 통해 이슈 처리를 할 수 있도록 하였음

(출처 : 요약문 5p)

목차 Contents

• 표지 ... 1
• 정보통신·방송 연구개발 (3연차·1단계) 보고서 ... 2
• 제 출 문 ... 3
• 연 차 보 고 서 ... 4
• 연 구 성 과 요 약 문 ... 5
• 목차 ... 8
• Ⅰ. 해당 연도 추진 현황 ... 9
• 가. 기술개발 추진 일정 ... 9
• Ⅱ. 기술개발결과 ... 10
• 가. 당해 기술개발 성과 목표 및 달성도 ... 10
• 나. 당해 정량적 성과목표 및 달성도 ... 12
• 다. 인력양성 성과 ... 13
• 라. 해당연도 기술개발 결과 ... 15
• Ⅲ. 공개SW R&D 전략 및 활성화 성과 ... 76
• 가. 공개SW 활성화 성과요약 ... 76
• 나. 공개SW R&D 전략의 적절성 및 활성화 노력 ... 76
• Ⅳ. 예산 사용 실적 ... 78
• 가. 당해연도 사업비 사용 실적 ... 78
• Ⅴ. 유형적 발생품(연구시설, 연구장비 등) 구입 및 관리 현황 ... 79
• 차년도 계획(요약서) ... 80
• 붙임1. 자체 보안관리 진단표 ... 83
• 붙임2. 연구실 안전조치 이행표 ... 84
• 끝페이지 ... 85