디스크 읽기 방식

✅ Sequential I/O & Random I/O

면접을 위한 답!

📌 랜덤 I/O와 순차 I/O는 저장 장치의 관점으로 데이터가 불연속적으로 있어 디스크 헤더를 이동 시키고 다음 데이터를 읽어 오는 것을 랜덤 I/O라고 하고, 데이터가 연속적으로 있어 그 데이터를 순차적으로 읽기만 하는 경우를 순차 I/O라고 합니다. 두 I/O를 비교했을 때 순차 I/O가 속도가 더 빨라 이상적으로는 랜덤 I/O를 순차 I/O로 바꾸는 방식으로 쿼리를 튜닝해야 하지만 그러한 방법이 많지 않기 때문에 쿼리를 처리하는데 꼭 필요한 데이터만 읽도록 쿼리를 개선하는 것을 목표로하고 그것이 또한 랜덤 I/O를 줄이는 것이라고 할 수 있습니다.

📌 The way to convert Random to Sequential I/O

1. 파일 할당 및 정렬 : 파일을 생성할 때 파일 시스템이 순차 I/O를 지원하는 블록 크기로 파일을 할당하고, 파일의 레코드를 정렬하여 순차적인 접근을 촉진한다.
2. 파일 시스템 최적화 : 일부 파일 시스템은 순차 I/O를 더 효율적으로 처리할 수 있도록 설계되어 있기 때문에 최적화를 진행한다. 이를 통해 대량의 데이터를 다루는 상황에서 랜덤 I/O의 부담을 감소시킬 수 있습니다.
3. 버퍼링 & 캐싱 : 시스템이 랜덤 I/O를 감지하고 이를 캐시에 저장하여 다음에 해당 데이터를 읽을 때 순차적으로 액세스하도록 한다.
4. 파일 접근 패턴 최적화 : 응용 프로그램이 파일에 접근하는 패턴을 최적화한다.
5. I/O 스케쥴링 : I/O Scheduler를 조정하여 데이터가 연속적으로 처리되게 끔 촉진할 수 있습니다.

📌 추가 설명
1. 만약에 대용량의 데이터에 대한 처리를 할 경우 순차 I/O가 빠르긴하지만 동기화를 여러번 해야하는 상황이 온다면 이 또한 비효율적으로 이뤄 질 수 있는데 이때 RAID 컨트롤러의 캐시 메모리를 이용하여 동기화 작업을 줄여 효율적으로 처리할 수 있게 만듭니다.

---

공부한 내용

현재 세상에는 다양한 종류의 드라이브가 발명이 되고, 속도도 점점 향상되고 있지만 여전히 컴퓨터에서 가장 느린 부분이라는 사실에는 변함이 없다. 이러한 속도가 느린 장치를 효율적으로 사용하기 위해 디스크 I/O를 어떻게 줄이느냐가 관건 일 때가 많다.

💡 짧게 말할 수 있는 SSD와 HDD의 차이
HDD는 데이터 저장용 플레터를 가지고 있지만, SSD는 이를 제거하고 플래시 메모리를 장착하고 있다.(플래쉬 메모리는 전원이 공급되지 않아도 데이터가 삭제 되지 않는다.) 그리고 이러한 플래쉬 메모리는 D-RAM보다는 느리지만, HDD보다는 훨씬 빠른 속도를 보인다. 그래서 DBMS용으로 SSD를 많이 채택하고 있다.

• RANDOM I/O
  하드 디스크 드라이브 플래터(원판)를 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽는 것을 의미하는데, 이러한 과정은 SEQUENTAIL I/O 또한 같다. 그럼에도 이 둘을 분류하는 기준은 디스크 헤더의 위치의 이동 없이 얼마나 많은 데이터를 한 번에 기록하느냐에 따라 결정된다. DBMS의 이러한 데이터를 읽고 쓰는 작업은 MySQL 서버에는 그룹 커밋이나 바이너리 고르 버퍼 또는 InnoDB 로그 버퍼 등의 기능이 내장돼 있다.

🔎 InnoDB 로그 버퍼란?

MySQL에서 데이터 처리 작업 중에 발생하는 트랜잭션 로그를 일시적으로 저장하는 공간이다. 이 로그는 데이터 변경 작업이 발생할 때마다 기록되며, 데이터베이스의 일관성과 내구성을 보장하는데 중요한 역할을 한다.
1. 트랜잭션 로그 기록 (INSERT , UPDATE, DELETE)
2. 재실행 및 롤백 지원 : 트랜잭션 도중에 시스템이 중단되는 경우 버퍼에 저장된 트랜잭션의 로그를 사용하여 DB를 복구 할 수 있다.
3. 쓰기 성능 향상 : InnoDB 로그 버퍼는 메모리에 위치하므로 디스크 I/O를 줄일 수 있다. 변경된 데이터가 먼저 로그 버퍼에 기록되고 나중에 실제 반영이 되기에 효율적인 쓰기 작업이 가능하다.
4. InnoDB 로그 버퍼를 통하여 성능 튜닝을 할 수 있으나, 메모리 사용량을 적정하게 조절하며 사용을 해야한다.

위 사진에서 확인을 해보면 순차 I/O는 랜덤 I/O 보다 3배더 빠른 작업을 한다고 볼 수 있다. 그래서 여러 번 쓰기 또는 읽기 요청을 하는 랜덤 I/O가 훨씬 부하가 크다. 이러한 점에서 볼 때 SSD에서는 적용이 안될 것이라고 생각할 수 있지만 전혀 아니다.

💡 SSD에서의 Sequential & Random I/O도 Random I/O는 Sequential I/O의 스루풋(통신에서 네트워크 상의 어떤 노드나 터미널로부터 또 다른 터미널로 전달되는 단위 시간당 디지털 데이터 전송으로 처리하는 양, 전체 처리율)이 떨어진다. 그래서 SSD에서도 둘의 성능 비교를 구분해서 명시한다.

---

✅ Index란? & 인덱스의 동작 방식 & How to set up Index? & 테이블에 인덱스를 많이 설정하면?

면접을 위한 답

📌 INDEX는 책의 찾아보기("색인")이라고 할 수 있습니다. 이러한 Spread Sheet의 레코드의 주소에 비유할 수 있습니다. 그리고, 인덱스는 빠른 조회를 위해서 항상 정렬되어 있다는 특징에 의해 DBMS에서 인덱스는 데이터의 저장 성능을 희생하고 대신 데이터의 읽기 속도를 높이는 기능을 하고 있습니다. ➡️ DB에서 테이블에 대한 검색 속도를 향상 시켜주는 자료구조이다. 이러한 인덱스를 이용하여 데이터베이스에서 기본키를 찾고 그 기본 키를 이용하여 해당 레코드를 찾을 수 있기 때문에 인덱스가 필요합니다.

이렇게 모든 것을 저장하지 않고 SELECT / WHERE 조건절을 사용하여 원하는 Column에 대하여 인덱스를 생성한다고 하여도 큰 틀을 정하고 생성하지 않으면 데이터 저장 성능이 떨어지고 크기가 비대해져 역효과가 날 수 있습니다. 그리고 C,R,U,D가 잦은 컬럼에 대해서는 인덱스 또한 수정되어야 하고 인덱스는 제거되는 것이 아닌 비활성화 상태로 남기 때문에 인덱스가 과도하게 커질 위험이 있습니다. 그래서 데이터를 읽는 속도를 높이기 위해서 알고리즘과 중복 값의 허용 여부 등에 따라 사용자가 임의로 여러 분류로 나눈 것입니다. 이렇게 알고리즘을 사용하여 데이터를 관리하는 경우 대표적으로 B-Tree Index, Hash Index, Fractal-Tree Index, Merge-Tree Index를 댈 수 있습니다.

---

🔎 Index 생성 방법

CREATE INDEX idx_age ON users(age);

위와 같은 방법으로 정렬이 되어있는 인덱스를 생성하고 알 수 있는 인덱스의 특징은, SELECT-FROM-WHERE 절 중 WHERE 절에서 사용할 컬럼에 대한 효율화라고 할 수 있습니다. 즉, WHERE절을 사용하지 않고 인덱스를 가진 컬럼을 조회하는 것은 성능 향상에 아무런 영향을 주지 못한다는 의미입니다.

✅ 인덱스를 많이 설정하면 어떻게 될까?

WHERE절을 인덱스가 있는 칼럼에 조회를 하여 효율성을 극대화하려고 해도 인덱스는 단일 인덱스만이 아닌 여러개의 컬럼을 묶어서 복합 인덱스를 형성하는 경우도 있기 때문에 밑의 좋은 사용 예시에 맞게 인덱스를 설정하는 것이 중요하다! 그렇지 않으면 DML(데이터 조작어, SELECT,INSERT, DELETE, UPDATE )의 효율성을 오히려 저하시키는 원인이 될 수 있다.

🔎 Index 사용의 좋은 예시

• 규모가 큰 테이블
• C,R,U,D 의 작업이 자주 발생하지 않는 컬럼 (활용도)
• WHERE이나 ORDER BY, JOIN 등이 자주 사용되는 컬럼 (선택도)
• 데이터의 중복도가 낮은 컬럼(중복도)
• 카디널리티가 높은 컬럼(카디널리티란, 인덱스에 해당하는 컬럼 기준으로 테이블에서 유일한 레코드의 개수를 의미한다. 즉, 컬럼에서의 중복 수치를 나타낼 수 있다.)

🔆 More comphrehension on Index

🔆 Structure of Index

인덱스를 더 자세하게 알려면, Hash 테이블과 B+ 테이블에 대해서 알아야 합니다.

🔆 What is a Page?

페이지란 디스크와 메모리(버퍼풀)에 데이터를 읽고 쓰는 최소 작업 단위이다. 인덱스를 포함해 기본키(클러스터 인덱스)와 테이블 등은 모두 페이지 단위로 관리 됩니다. 즉, 데이터를 논리적으로 혹은 물리적을 구성하는 최소 작업 단위라고 이해할 수 있다.

💡 Clustered-indexing
클러스터 인덱스는 인덱싱의 기본 타입을 테이블의 결정자와 기본키에 의해서 데이터가 정렬되는 인덱싱 타입입니다.

🔆 Hash Table

Key와 Value를 한 쌍으로 데이터를 저장하는 자료구조이다. 인덱스 값이 데이터 값에 대한 키로 동작하기 때문에 매우 빠른 데이터 읽기가 가능합니다. 즉, 해시 테이블은 Key-Value 쌍을 저장하지만 Key는 해싱 함수를 통해 생성됩니다.(중복이 없이 생성하여ㅡ 각 키를 고유한 해시 값으로 매핑하여 빠르게 찾기 위함이다.)

해싱의 개념은 버킷 배열에 키-값의 쌍을 배포하는 것입니다. 해시 테이블의 시간 복잡도는 O(1)이며 매우 빠른 검색을 지원합니다. 하지만, 해시가 등호 연산(=)에만 특화되어 있기 때문에, DB에서는 많이 사용되지 않습니다.

---

✅ 커버링 인덱스 & 다중 컬럼 인덱스

커버링 인덱스라는 것은 쿼리를 충족시키는데 있어 필요한 모든 데이터를 갖고 있는 인덱스를 말하고, 다중 컬럼 인덱스는

---

✅ B-Tree 인덱스와 B+Tree 인덱스에 대해 설명해주세요.

면접을 위한 답

📌 B-Tree 와 B+Tree는 인덱스를 구현하는 트리 구조입니다. B+Tree는 B-Tree의 변형으로, 리프 노드에만 값을 담아 놓고 연결 리스트로 연결되어 있어 범위 검색이나 정렬된 결과 반환에 효과적이라는 특징이 있습니다.

---

📖 공부한 내용

🌲 B-Tree

💡 B-Tree는 DB의 인덱싱 알고리즘 가운데 가장 일반적으로 사용되고, 가장 먼저 도입된 알고리즘이다. 하지만 아직도 가장 범용적인 목적으로 사용된다. B-Tree를 기준으로 다양하게 변형되어 사용되는데 그렇게 InnoDB를 이루는 B+Tree 등이 탄생하게 되었디.

💡 B-Tree의 구조 및 특성

• 첫 사진에서 알 수 있듯이, B-Tree 구조는 모든 노드에 값을 담고, 최상위에 Root Node가 있고 그 하위에 자식 노드가 붙어 있으며 최하위에는 Leaf Node가 있음을 알 수 있다. 중간의 node들은 Branch Node라고 부른다.
• 인덱스는 검색의 효율성을 높이기 위해 정렬돼 있지만, 데이터 파일의 레코드는 정렬하지 않고 임의로 저장되어 있다. 즉, 데이터 파일의 레코드는 INSERT한 순서대로 저장되는 것이 아니다. 중간에 어떤 레코드가 삭제되어 공간이 생기면 그 공간을 계속 재활용하기 때문이다.

• 위 사진에서 확인 할 수 있듯이, 인덱스는 키 값에 대한 정보만 가지고 있기 때문에 나머지 컬럼에 대한 정보를 읽기 위해서는 데이터 파일에서 해당 레코드를 찾아야 한다. 그를 위해 테이블의 기본키를 통해서(논리적인 주소 할당) 노드를 파해쳐 들어가 리프노드 안의 내가 원하는 정보를 찾는다.

• 위 사진에서 보듯이 리프 노드에 인덱스 키, 기본키의 쌍으로 저장되어 있음을 볼 수 있다. 인덱스는 테이블과 독립적인 저장 공간이므로 인덱스를 통해 데이터를 조회하려면 먼저 Primary Key를 찾아야 한다. 기본키로 레코드를 찾을 때는 기본키가 어느 페이지에 저장 되어 있는지 알 수 없으므로 랜덤 I/O가 발생하고 이후에는 기본키를 따라 리프노드에 실제 레코드를 읽어옵니다.

💡 B-Tree 인덱스 키 추가 및 삭제

• 인덱스 키 추가
  내가 입력한 값이 즉시 반영될지 안될지를 모르기 때문에 B-Tree에 값을 저장할 때 B-Tree의 상의 적절한 위치를 검색해야 한다. 그후 저장할 위치가 결정되면 B-Tree의 리프노드에 레코드의 키 값과 주소 정보를 저장한다. 만약 저장하다가 리프노드의 공간이 다 차게 되면 그 상위노드로 넘어가 정보를 처리한다. 이 과정을 저장을 완료할때 까지 반복한다.
  - 이러한 점 때문에, B-Tree에서 인덱스 키 추가는 비용이 많이 든다고 알려진다.
  

• 인덱스 키 삭제
  아주 간단하게 B-Tree의 리프 노드를 찾아서 삭제 마크만 하면 작업이 완료된다.완전히 삭제되는것이 아니기 때문에 계속 방치하거나 재활용 될 수 있다.

• 인덱스 키 변경
  B-Tree의 키 값을 변경하는 경우에는, 일단 해당 키 값을 삭제한 후, 다시 새로운 키 값을 추가하는 형태로 처리된다. 이러한 변경하는 과정 중 발생하는 추가와 삭제는 위의 과정과 같다.
  

• 인덱스 키 검색
  트리탐색 작업과 매우 유사하게 진행된다. 루트 노드로 부터 시작해 매번 n-way 결정을 내리게 된다. 여기서 n은 자식 노드의 개수를 말하고 이에 따라 시간 복잡도는 O(log n) 에 수행된다.
  검색 요소 읽기 ➡️ 검색 요소를 트리에서 루트 노드의 첫 번째 키 값과 비교 ➡️ 둘 다 일치하는 경우 찾았음을 표시 후 함수 종료 ➡️ 일치 하지 않을 경우 검색 요소를 해당 키 값도다 작거나 큰지 비교 연산자를 통해 확인 ➡️ 키 값이 작은 경우 하위 트리에서 같은 과정을 반복한다. ➡️ 만약 검색 요소가 더 크면 동일한 노드의 다음 키 값과 비교하고 정확히 일치하는 항목을 찾거나 검색 요소가 마지막 키 값과 비교할 때까지 위 과정을 반복한다. ➡️ 리프노드의 마지막에도 찾을 수 없으면 찾을 수 없음에 대한 메세지를 표시하고 종료한다.
  

✅ 트리탐색 : Root Node ➡️ Branch Node ➡️ Leaf Node로 이동하며 비교 작업을 수행하는 것

---

🌲 B+Tree

💡 B+Tree는 B-Tree의 확장 개념으로, 브랜치 노드에 키값만 담아두고, 데이터는 담아 두지 않는다. 오직 leaf 노드에만 키와 밸류 데이터를 저장하고 나머지 노드들은 데이터를 위한 인덱스(Key)만을 가지고, leaf node끼리 연결 리스트로서 이어져 있다. B-Tree의 장점은 한 노드당 자식 노드가 2개 이상이 가능하기에 검색면에서 빠르게 가능하다는 장점이 있었는데 B+Tree는 리프노드를 제외하고는 데이터를 저장하지 않기 때문에 메모리를 더 확보하여 더 많은 키값을 수용하여 트리의 높이를 낮출 수 있다. 그리고 풀스캔 시에는 B-Tree보다 속도가 빠르다.

Hash 인덱스에 대해서 설명해주세요.

✅ 클러스터링 인덱스에 대해서 설명해주세요.

물

인덱스 스캔 방식에 대해서 설명해주세요

쿼리 실행 계획에 대해서 설명해주세요. 실행 계획을 확인해본 적이 있나요?

힌트에 대해서 설명해주세요.

인덱스가 잘 동작하고 있는지 어떻게 확인할 수 있을까요? / 인덱스 사용시 주의해야할 점에 대해서 알려주세요.

GROUP BY 사용시 인덱스가 걸리는 조건에 대해 설명해주세요.

이름, 국가, 성별이 있는 테이블에서 인덱스를 어떻게 걸어야할까요?

REFERENCES
1. SEQUENTIAL & RANDOM
2. Real MySQL
3. B-Tree/B+Tree
4.Basic definition of Index