일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 자료구조
- 정규화
- JPA
- gatway
- 삽입 이상
- Redis
- ocp
- Kotlin
- Dirty Checking
- Kafka
- 캐시 오염
- Spring
- 네트워크
- HTTP
- 데이터베이스
- 자바
- MSA
- AWS
- 갱신 이상
- 스레드 풀
- buildSrc
- null
- 페이지네이션
- 낙관적 락
- java
- 비관적 락
- well-know port
- DB
- 3-way handshaking
- 삭제 이상
- Today
- Total
어 나 갱수.
[DB] 인덱스(Index)란? 😛 본문
오늘은 Index에 대해 알아보겠습니다.
인덱스(Index)란 ?
인덱스란 추가적으로 저장 공간을 만들어서 데이터베이스 테이블의 검색 속도를 향상하기 위한 자료구조입니다.
예를 들어 만약 책에서 원하는 내용을 찾는다면 책의 모든 페이지를 하나하나 확인하면서 책의 원하는 내용을 찾는 거는 너무 비효율적인 방법입니다. 이런 비효율을 막기 위해 책의 맨 앞에 목차를 두고 원하는 위치에서 정보를 얻을 수 있도록 하고 있는데요.
정리하면 데이터는 책의 내용, 인덱스는 책의 목차, 데이터의 물리적인 주소는 책의 페이지라고 생각하면 됩니다.
특정 칼럼(필드)에 대한 인덱스를 생성하게 되면 해당 칼럼의 데이터들을 정렬해서 별도의 메모리에 저장합니다.
인덱스를 활용하면 검색속도가 빨라진다는데 어떻게 빨라진다는 걸까요 ?
위에서 말했다시피 인덱스를 생성한다는 것은 뒤죽박죽인 데이터들을 정렬해서 별도의 메모리에 저장해 놓는다는 의미였습니다.
메모리에 미리 저장된 데이터의 물리적인 주소로 가서 데이터를 가져와서 검색 속도를 향상할 수 있는 것이죠.
교과서를 예로 들어보겠습니다. 책의 목차를 보고 내가 원하는 정보가 5단원에 있다는 것을 확인하고 1~4단원 페이지를 보지 않고 5단원을 바로 확인하면 빠르게 데이터를 검색하고 가져올 수 있다는 것입니다.
장점
1. 조건 검색 WHERE 절의 효율성
테이블을 생성하고 안에 데이터를 넣게 되면 데이터들은 규칙이 없이 뒤죽박죽으로 저장이 됩니다.
이렇게 되면 쿼리문에서 WHERE 절이 실행되면서 조건에 맞는 데이터를 찾을 때 데이터베이스를 모두 다 읽어서 조건에 맞는 데이터를 찾아야 합니다. 이것을 풀 테이블 스캔 (Full Table Scan), 줄여서 풀 스캔(Full Scan)이라고 합니다.
하지만 인덱스를 사용하면 데이터들이 정렬되어 저장되어 있기 때문에 해당 조건에 맞는 데이터를 검색할 때 빠르게 검색할 수 있습니다.
2. MIN, MAX의 효율적인 처리가 가능하다
데이터들이 정렬되어 있기 때문에 얻을 수 있는 장점입니다. MIN값과 MAX값은 정렬된 데이터의 시작 값과 끝 값을 가져오기만 하면 구할 수 있기 때문입니다. 풀 스캔으로 테이블을 모두 검색하면서 값을 찾는 것보다 훨씬 효율적으로 데이터를 검색할 수 있습니다.
단점
1. 인덱스는 DML에 취약
DML문인 INSERT, DELETE, UPDATE를 통해 데이터베이스에 데이터가 변경된다면 인덱스의 데이터를 다시 정렬해야 한다
그렇기 때문에 DML이 빈번하게 일어나는 테이블보다는 검색을 많이 하는 테이블에 인덱스를 생성하는 것이 좋다.
2. 인덱스 스캔이 무조건 좋은 것은 아님
검색을 위주로 하는 테이블에 인덱스를 생성하는 것이 좋지만 무조건 좋은 것은 아니다.
인덱스는 테이블의 전체 데이터 중에서 10~15% 이하의 데이터를 처리하는 경우에만 효율적이고 그 이상의 데이터를 처리할 땐 인덱스를 사용하지 않는 것이 더 낫다.
3. 인덱스의 저장공간
모든 테이블에서 무턱대고 인덱스를 생성하는 것은 좋지 않다. 인덱스를 생성하게 되면 데이터베이스에서 약 10%의 저장공간을 더 요구한다. 효율적으로 인덱스를 생성하고 사용할 필요가 있다.
인덱스 관리
인덱스는 항상 데이터베이스 테이블에 있는 최신 데이터를 정렬상태로 유지해야 원하는 값을 빠르고 효율적으로 찾을 수 있습니다.
따라서 데이터베이스에 INSERT, DELETE, UPDATE와 같은 DML문이 수행된다면 추가적으로 연산을 해서 인덱스를 다시 정렬해주어야 합니다.
인덱스의 자료구조
인덱스는 여러 자료구조를 사용해서 구현할 수 있습니다. 대표적인 자료구조로는 해시 테이블과 B+Tree 자료구조가 있습니다.
해시 테이블(Hash Table)
해시 테이블은 키(Key)와 해시 값(Hash Value) 쌍으로 이루어진 자료구조입니다.
해시 테이블의 검색 방법은 키를 통해서 해시 함수를 실행시키고 해시 값으로 변환되면 해시 값으로 데이터를 찾는 방식입니다.
해시 테이블은 속도가 매우 빠르나 충돌이 발생할 수 있습니다.
B-Tree
사각형으로 표시된 한 개 한 개의 데이터를 노드라고 한다.
가장 상단의 노드를 루트노드, 중간 노드들을 브랜치 노드, 가장 아래에 있는 노드들을 리프 노드 라고 한다.
노드 하나에는 여러 가지 데이터가 저장될 수 있다.
각 노드에 데이터는 항상 정렬된 상태를 유지하고 있다.
B+Tree
기존의 B-Tree는 어느 한 데이터의 검색은 효율적이지만, 모든 데이터를 한 번 순회하는 데에는 모든 노드를 방문해야 하므로 비효율적이다. 이러한 B-Tree의 단점을 개선시킨 자료구조가 B+Tree이다.
B-Tree는 각 노드에 데이터를 저장하지만, B+Tree 는 오직 leaf node에만 데이터를 저장하고 leaf node가 아닌 node에서는 자식 노드의 주소를 저장한다. leaf node 끼리는 Linked list로 연결되어 있다.
B+Tree를 사용하면 뭐가 좋을까?
Full Scan을 하는 경우 B+Tree는 leaf node에만 데이터가 저장되어 있고, leaf node끼리는 Linked list로 연결되어 있기 때문에 선형 시간이 소모된다. 반면 B-Tree는 모든 node를 확인해봐야 한다.
그러나 B-Tree를 사용할 때 최상의 경우 root node에서 데이터를 찾을 수 있지만, B+Tree에서는 leaf node까지 가야 한다는 단점이 있다.
정리
- 인덱스란 테이블에 있는 데이터의 검색 속도를 향상하기 위해 사용되는 자료구조이다.
- 인덱스를 생성하면 내가 원하는 데이터가 정렬된 상태로 저장된다.
- 테이블의 삽입, 삭제, 수정보다는 테이블의 데이터를 검색이 많은 경우 인덱스의 사용이 적합하다.
- 테이블의 삽입, 삭제, 수정이 일어나면 인덱스의 정렬을 다시 해야 하기 때문이다.
- 인덱스를 관리하려면 데이터베이스의 약 10% 저장 공간이 필요하므로 적절하게 생성하고 사용하는 것이 중요하다.
'DB' 카테고리의 다른 글
[DB] INNER 조인 & OUTER조인 🤚 (0) | 2024.02.29 |
---|---|
[DB] 정규화란 ? 🐼 (1) | 2024.02.04 |
[DB] DBCP 이란? 🫶 (0) | 2024.01.28 |
[DB] 이상 현상이란 ??👍🏿 (0) | 2024.01.25 |
[DB] Redis를 왜 사용할까 ?? 🥱 (0) | 2023.11.29 |