MySQL InnoDB의 Adaptive Hash Index

최근 DB에 대해 부족함을 느껴, Real MYSQL 8.0 책을 읽고 있다.

Real MYSQL 8.0의 Adaptive Hash Index에 대해 더 궁금하여, 아래 글을 보고 정리하였다.

https://tech.kakao.com/posts/319

MySQL InnoDB의 Adaptive Hash Index 활용 - tech.kakao.com

 

InnoDB B-Tree 인덱스

MySQL의 InnoDB의 대표적인 인덱스는 B-Tree이다.

데이터는 Primary Key 순으로 정렬되어 관리되고, Secondrary Key는 인덱스키+PK를 조합으로 정렬

특정 데이터를 찾기 위해서는 Secondrary Key에서 PK를 찾고, 그 PK를 통해 다시 원하는 데이터로 찾아가는 형태로 데이터가 처리된다.

트리의 가장 큰 강점은 데이터 접근 퍼포먼스가 데이터 증가량에 따라서도 결코 선형적으로 증가하지 않다는 점에 있다.

참고로, PK 접근 시 데이터 접근에 소요되는 비용은 O(logN)이고, 두번 트리에 접근하는 Secondrary Key에 소요되는 비용은 2 * O(logN)입니다.

 

 

B-Tree 인덱스: Primary Key vs Secondary Key

데이터가 아무리 많아져도, 데이터 접근에 소요되는 비용이 크게 증가되지 않음에도, 상황에 따라 효율이 좋지 않다. 자주 사용되는 데이터 탐색에도 매번 트리의 경로를 쫓아가야 한다는 점.

게다가 Mutex Lock이 과도하게 잡히게 되면, 적은 데이터 셋에도 불구하고 DB 자원 사용 효율이 떨어진다.

InnoDB Adaptive Hash Index

InnoDB에서는 앞서 언급한 상황을 해결하기 위해, InnoDB Adative Hash Index 기능이 있다. 자주 사용되는 칼럼을 해시로 정의하여, B-Tree 를 타지 않고 바로 데이터에 접근할 수 있는 기능

“Adaptive”라는 단어에서 예상할 수 있겠지만, 모든 값들이 해시로 생성이 되는 것이 아니라, 자주 사용되는 데이터 값만 내부적으로 판단하여 상황에 맞게 해시 값을 생성한다.

Adative Hash Index

즉, 전체 데이터를 대상으로 해시값을 생성하지는 않는다.

Adative Hash Index에 할당되는 메모리는 전체 Innodb_Buffer_Pool_Size의 1/64만큼으로 초기화된다.

최소 메모리 할당은 저렇게 할당되나, 최대 사용되는 메모리 양은 알 수는 없다. 서버의 특성마다 다르겠지만, Apdaptive Hash Index를 활성화한 경우 반드시 현재 사용하고 있는 관련 메모리를 모니터링을 해야합니다. 

 

자주 사용되는 자원을 해시를 통해서 직접 접근하기 때문에, 내부적인 락(이를테면 Mutex)으로 인한 지연이 줄어듭니다. 게다가 B-Tree의 데이터 접근 비용(O(LogN))에 비해, 해시 데이터 접근 비용인 O(1)으로 굉장히 빠른 속도로 데이터 처리가 가능한 것이죠. 단 자주 사용되는 자원 만을 해시로 생성하기 때문에, 단 건 SELECT로 인하여 반드시 해당 자원을 향한 직접적인 해시 값이 만들어지지 않습니다.

 

성능 향상에 도움이 되는 경우

• 디스크의 데이터가 InnoDB 버퍼 풀 크기와 비슷한 경우(디스크 읽기가 많지 않은 경우)
• 동등 조건 검색(동등 비교와 IN 연산자)이 많은 경우
• 쿼리가 데이터 중에서 일부 데이터에만 집중되는 경우

성능 향상에 무관한 경우

• 디스크 읽기가 많은 경우
• 특정 패턴의 쿼리가 많은 경우(JOIN이나 LIKE 패턴 검색)
• 매우 큰 데이터를 가진 테이블의 레코드를 폭넓게 읽는 경우