데이터베이스에 인덱스가 없다면 테이블에 데이터가 삽입되는 순서는 특정 제약이 없다. 또한 데이터 조회 시(일반적인 where절 사용) 테이블 풀스캔이 발생한다. 이때 match 되는 데이터를 찾더라도 데이터 순회를 끝내는 것이 아니라, 테이블의 끝까지 데이터를 '순차 탐색'하면서 match 되는 데이터를 '모두' 찾는다. 이러한 테이블 풀스캔이 항상 나쁘다고 할 순 없지만 데이터가 많아질수록 성능에 문제가 발생할 것이다. 물리적으로는 한 테이블의 데이터 record들이 위와 같은 페이지 구조로 저장된다. 만약 record들을 특정 컬럼 기준으로 정렬해서 저장한다고 하면 테이블 풀스캔을 하지 않고도 찾고자 하는 데이터를 찾을 순 있지만 순차 탐색을 해야 한다는 단점이 존재한다. 이를 해결하기 위한 가장 대..
Type Of Index single level index composite index multilevel index 1. Single Level Index - 인덱싱하는 컬럼이 1개인 경우에 해당함 - primary key에 걸면 Primary Index(기본 인덱스), 다른 컬럼에 걸면 Secondary Index(보조 인덱스) - SQL문에서 where = {key1} = {value1} 가 하나인 경우 equality search가 빠르다. - 메모리에 index table의 데이터 크기가 table보다 작음 - 카디널리티가 매우 낮은 컬럼이라면 인덱스를 지정하지 않는 것이 더 나을 수도 있음 [인덱스 정렬 타입] 1) Dense Index(밀집 인덱스) - 한 인덱스에 원하는 데이터가 바로 매칭..
Balanced Tree - 한쪽으로 노드가 몰리는 Binary Search Tree의 단점을 보완하고자 등장 - DBMS에서 가장 범용적으로 사용되는 자료구조 - Binary Search Tree와 유사하지만 depth를 자동으로 잡아주기 때문에 탐색 시간복잡도가 O(logN)을 보장함 - 하지만 depth에 영향을 줄 수 있는 insert, delete 경우에 대해서는 성능이 좋지 않을 수 있음 - 결론적으로, 데이터를 얼마나 자주 삽입, 삭제할 것인가에 따라서 B-Tree Index를 활용할지 말지를 결정 - 즉, 갱신 빈도가 높은 테이블에 인덱스를 지정할 경우, 인덱스 재구성 발생 빈도가 높아진다는 점을 고려해야 함 B-Tree - 하나의 노드에 여러개의 값이 배치되는 구조의 트리 - 차수 M의 ..
- Total
- Today
- Yesterday
- Java
- GitOps
- rolling update
- spring
- 쿠버네티스
- Stream
- db
- jvm
- Non-Blocking
- 컨트롤러
- LFCS
- ci/cd
- 카프카
- docker
- RDB
- kafka
- 코틀린
- CICD
- 우분투
- helm
- ubuntu
- K8s
- Linux
- Kubernetes
- argocd
- container
- go
- github actions
- Controller
- golang
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |