성능 개선을 위한 인덱스의 활용과 B-Tree

[HJ-Rich]

주제

• 8.1 디스크 읽기 방식
• 8.2 인덱스란?
• 8.3 B-Tree 인덱스
• 8.8 클러스터링 인덱스

선정 이유

• 8.1과 8.2는 인덱스를 이해하기 위한 기초지식에 해당한다고 생각해요
• 8.3과 8.8이 8장에서 가장 중점적으로 이해해야 하는 대상이라고 생각해요
• 그렇긴 한데... 한 번에 다 온전히 지식을 내재화하긴 어렵다고 느꼈어요
  • 이해되는 부분까지 학습하고, 대화해보고, 시간을 두고 다시 읽어봐야할 것 같아요

해당 텍스트

논하고자 하는 근본적인 주제는 바로 성능 개선!

• 성능 개선의 방법으로 인덱스를 소개하는 장입니다.
• 그 중에서도 InnoDB에서 사용되는 B-Tree 인덱스 알고리즘과 클러스터링에 대한 소개입니다.

데이터베이스 성능 개선이란 곧 디스크 I/O 줄이기

• 데이터 저장 매체는 컴퓨터에서 가장 느린 부분입니다. (CPU, 메모리 등에 비교해서요)
• 따라서 DB 성능 튜닝은 곧 어떻게 디스크 I/O를 줄일 것이냐로 귀결됩니다.
• 일반적 애플리케이션에선 랜덤 I/O 가 빈번하게 일어나고, 이를 줄이려면 쿼리를 튜닝해야 합니다.
• 쿼리 튜닝의 방법 중 하나로 인덱스가 있습니다.

인덱스는 R을 위해 CUD를 희생하는 것

• 인덱스는 항상 정렬을 해두었다가 검색시 쉽게 찾겠다는 컨셉입니다.
• 반면, 삽입이나 삭제, 수정이 일어났을 때에도 정렬을 유지해야 하기 때문에 비용이 발생합니다.
• 일반적 애플리케이션에선 읽기 : 쓰기 비율이 8:2 정도 라고 합니다.
• 따라서 읽기 성능을 끌어올리는 것이 애플리케이션 전체 성능 및 사용성 개선에 도움이 됩니다.

B-Tree 인덱스 알고리즘

• Balanced Tree의 약자인 B-Tree 인덱스 알고리즘은, 가장 범용적으로 사용되는 일반용도에 적합한 인덱스 알고리즘 입니다.
• 인덱스로 설정한 컬럼의 값을 변형시키지 않으며, 정렬된 상태를 유지합니다.
• 루트 노드 -> 브랜치 노드 -> 리프 노드 의 구조를 띕니다.
• 비슷한 값들을 카테고리화 하여 하위 요소를 빠르게 탐색하기 위함입니다.
• 리프 노드에는 인덱스 키와 실제 데이터를 찾아갈 수 있는 값이 저장됩니다.
• InnoDB에는 클러스터링이 기본 적용되어, B-Tree를 다시 탐색할 수 있는 PK값이 리프 노드 인덱스 키에 매칭되는 값으로 할당됩니다.
• 즉, 리프 노드에서 발견된 논리 주소를 이용해, B-Tree 를 다시 조회하는 것입니다.

클러스터링

• InnoDB 에서만 지원하고, 그 외 스토리지 엔진에선 지원하지 않습니다
• 프라이머리 키에 대해서만 적용됩니다.
• 프라이머리 키를 기준으로 비슷한 레코드끼리 묶어서 저장합니다.
  • 다시 말해, 키 값이 바뀌면 물리적 저장 위치도 바뀌어야한다는 뜻입니다.
• 일반적인 온라인 트랜잭션 환경에서 읽기, 쓰기 비율은 2:8 정도이기에, 쓰기 성능을 다소 희생하고 읽기 성능을 올릴 수 있다면 이것이 더 나은 선택이 될 수 있습니다.

B-Tree Insert, Delete, Update

• INSERT
  • 저장될 리프 노드 탐색한 뒤, 인덱스 키 값과 이에 해당하는 값을 저장.
  • InnoDB가 아닐 경우 데이터 파일의 물리 주소, InnoDB의 경우 클러스터링 된 PK 논리 주소. (질문!! 이거 맞나요?!)
  • 리프 노드가 차서 더 저장 불가하다면 (페이지 크기 초과), 리프 노드 분리(Split)이 일어난다.
  • 스플릿은 상위 브랜치 노드에도 영향을 미친다.
  • 이 스플릿 작업의 존재로 인해 쓰기 작업 비용이 비교적 크다. 이것이 R을 위해 희생해야할 대표적인 비용이다.

• DELETE
  • 대상 리프 노드를 찾아 삭제됐다고 마킹
  • MySQL 5.5 이상 & InnoDB 사용 시, 이를 디스크에 반영하는 작업은 지연 처리됩니다
  • 지연처리 되더라도 내부적으로 이슈 없으므로 걱정 안해도 됩니다
  • 질문!! 삭제될 때도 페이지 단위를 채우기 위해 재조정이 일어나나요? Split의 반대로 Merge 같은 느낌으루?!

• Update
  • 변경은 불가해서 삭제 후 재추가로 대체됩니다.
  • 삭제와 마찬가지로 InnoDB 체인지 버퍼를 활용해 지연 처리됩니다.

• Select
  • 100% 일치, 전방 일치, 부등호 연산에 인덱스가 사용됩니다.
  • 뒷부분만 검색하는 용도로는 지원되지 않습니다
  • 함수 혹은 연산 수행 결과로 정렬, 검색할 경우 B-Tree 장점 이용 불가합니다.
  • Update, Delete 시, 적절한 인덱스 없으면 테이블 전체를 잠글 수도 있다 실화군요;;

페이지

• InnoDB 스토리지 엔진이 디스크에 데이터를 저장하는 기본 단위
• 디스크 I/O 최소 작업 단위
• 버퍼 풀에서 데이터를 버퍼링하는 기본 단위이기도 합니다.
• 인덱스도 페이지 단위로 관리됩니다
• 루트, 브랜치, 리프 노드들도 페이지 단위로 구분됩니다
• 기본 크기는 16kb 입니다.
• 따라서 하나의 인덱스 페이지에 인덱스, 자식노드주소 가 담겨야 하는데, 인덱스 키의 크기가 커지면 하나의 페이지에 담길 수 있는 수가 줄어듭니다.
  • 이는 곧 I/O 횟수의 증가로 이어져 성능 저하로 귀결됩니다
• 여러 리프 노드에 걸쳐 조회를 하게 되면, 페이지 단위가 달라져서 I/O 횟수가 증가하게 되는 걸 알 수 있습니다.
• 인덱스 키의 크기가 노드의 깊이에도 영향을 주는 게 이론적으론 맞지만, 현실적으로 성능에 크게 영향을 미치진 않습니다. 거진 5단계 이상 깊어지지 않기 때문입니다.

질문

• InnoDB의 B-Tree의 인덱스를 이용한 하나의 레코드 조회를 시도했을 때 Flow 설명해주실분 😃
  • 논리 주소를 이용해 B-Tree를 다시 조회한다는 내용이 잘 이해되지 않았어요!
• 그 외에도 어려운 부분이 많았지만.. 제가 이번 이슈에서 다룬 네 장만 저는 이해해보기로 했습니다! 🎶

관련 페이지

• 8.1 디스크 읽기 방식
• 8.2 인덱스란?
• 8.3 B-Tree 인덱스
• 8.8 클러스터링 인덱스

[HJ-Rich]

• 삭제할 때도 재조정이 일어난다.
• InnoDB는 리프 노드의 인덱스 키에 밸류가 PK로 할당되어 있고, 이 PK로 레코드를 다시 조회한다