20240320 CS 스터디 - DB (2)

 

인덱스란?

인덱스란 테이블에 대한 검색 속도를 향상시켜주는 하나의 장치이다.

테이블의 특정 컬럼에 인덱스를 생성하면, 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장된다.

 

+) 조금 더 자세히 설명하자면, Disk에서 발생하는 I/O 시간은 Main Memory에서 발생하는 I/O에 비해 매우 크다. 따라서 DB를 통해 데이터를 검색시 Disk I/O가 빈번히 일어나지 않도록 하는 것이 유리할 것 같다. 이를 위해 Index를 사용한다. Index를 통해 Disk I/O 횟수를 최대한 줄여 DB 성능을 높일 수 있는 것이다. 따라서 Index는 DB에서 뿐만 아니라 random access를 할 때 사용하면 적합하다.

 

+) 인덱스의 방식 - ordered & hash

 

인덱스의 자료구조

1) 해시테이블 (Hash Table)

해시테이블은 key와 value를 한 쌍으로 저장하는 자료구조이다. 해시 충돌이라는 변수가 존재하지만, 평균적으로 O(1)의 매우 빠른 시간만에 원하는 데이터를 탐색할 수 있다.

 

해시테이블을 이용한다면 인덱스는 (key, value) = (컬럼의 값, 데이터의 위치)로 구현하는데, 해시테이블을 실제로 잘 사용되지 않는다.

그 이유는, 해시 테이블은 등호(=) 연산에 최적화되어있기 때문이다. 데이터베이스에선 부등호(<, >) 연산이 자주 사용되는데, 해시테이블 내의 데이터들은 정렬되어 있지 않으므로 특정 기준보다 크거나 작은 값을 빠른 시간 내에 찾을 수가 없다.

 

2) B-Tree

탐색 성능을 높이기 위해 균형 있게 높이를 유지하는 Balaced Tree의 일종이다.

모든 leaf node가 같은 level로 유지되도록 자동으로 밸런스를 맞춰준다. 자식 node의 개수가 2개 이상이며, node 내의 key가 1개 이상일 수 있다.

 

 

Balanced tree를 사용하는 이유가 무엇일까?

 

트리가 편향된 경우 최악의 시간복잡도로 O(N)을 갖게 된다. 트리가 편향되지 않게 항상 밸런스를 유지하는 Balanced tree를 사용하면, 최악의 경우에도 O(logN)의 시간이 보장되기 때문이다.

 

https://rebro.kr/169

[DB] 10. B-Tree (B-트리)

 

3) B+Tree

오직 leaf node에만 데이터를 저장하고, leaf node가 아닌 node에는 자식의 포인터만 저장한다. 그리고 leaf node끼리는 Linked list로 연결되어있다. 

B+Tree에서는 반드시 leaf node에만 데이터가 저장되기 때문에 중간 node에서 key를 올바르게 찾아가기 위해서 key가 중복될 수 있다.

 

이로 인한 장점이 무엇일까?

- leaf node를 제외하고 데이터를 저장하지 않기 때문에 메모리를 확보할 수 있다.

- Full scan을 하는 경우 B+Tree는 leaf node에만 데이터가 저장되어 있고, leaf node끼리 linked list로 연결되어 있기 때문에 선형 시간이 소모된다. (B-Tree는 모든 node를 확인해야한다.)

 

단점은?

B-Tree의 경우 최상의 경우 특정 key를 root node에서 찾을 수 있지만, B+Tree의 경우 반드시 특정 key에 접근하기 위해서 leaf node까지 가야 한다는 단점이 있다.

 

인덱스에서 B-Tree 대신 주로 B+Tree를 사용하는 이유는 뭘까?

인덱스 컬럼은 부등호(<, >)를 이용한 순차 검색 연산이 자주 발생할 수 있다. B+Tree는 모든 leaf node가 Linked list로 구성되어 있기 때문에 순차적인 데이터 액세스가 빠르다.

 

https://rebro.kr/167

[DB] 11. 인덱스(Index) - (1) 개념, 장단점, B+Tree 등

 

Primary index vs Secondary index

(1) 기본 인덱스 (Primary index)

ㅇㅇㅇ

 

[특징]

- 테이블 당 하나의 기본 인덱스만 가질 수 있다.

- 데이터 블록은 기본 인덱스 키를 기준으로 물리적으로 정렬된다. (기본인덱스는 실제 데이터 행이 저장되는 물리적 위치에 영향을 끼친다.)

 

매핑 크기가 커지면 주소 자체를 가져오는 속도가 느려진다.

이런 경우에 Sparse Index는 효율적이지 않게 된다. 이 문제를 해결하기 위해 Secondary Index가 생겼다.

 

(2) 보조 인덱스 (Secondary index)

매핑 크기를 줄이기 위해 

 

[특징]

- 테이블 당 여러개의 보조 인덱스를 가질 수 있다.

- 데이터블록은 보조 인덱스 키에 대하여 정렬된 행을 유지하지 않는다. (보조인덱스는 실제 데이터 행이 저장되는 물리적 위치에 영향을 끼치지 않는다.)

 

https://velog.io/@hyoeunla/Database-Primary-Index-vs-Secondary-Index

Database - Primary Index vs Secondary Index

 

Clustered index vs Non-Clustered index

 

https://charming-kyu.tistory.com/51

Clustered Index vs Non-Clustered Index

 

Composite index (복합인덱스)

여러 필드를 기반으로 조회를 할 때 복합 인덱스를 생성한다. 인덱스를 생성할 때 두 개 이상의 컬럼을 합쳐서 만든다.

복합 인덱스의 생성 순서에 따라 인덱스 성능이 달라진다.

같음, 정렬, 다중값, 카디널리티 순으로 생성해야 한다. (첫 번째 조건에서 최대한 많은 데이터를 걸러내서 두 번째 조건을 검사하도록 해야 한다.)

 

1) 어떠한 값과 같음을 비교하는 `==`이나 `equal`이라는 쿼리가 있다면 제일 먼저 인덱스로 설정한다.

2) 정렬에 쓰는 필드라면 그 다음 인덱스로 설정한다.

3) 다중값을 출력해야 하는 필드, 즉 쿼리 자체가 `>`이거나 `<` 등 많은 값을 출력해야 하는 쿼리에 쓰는 필드라면 나중에 인덱스를 설정한다.

4) 유니크한 값의 정도를 카디널리티라고 한다. 카디널리티가 높은 순서(유니크한 순서)를 기반으로 인덱스를 생성해야 한다.

ex. age와 email이 있다면, 카디널리티가 높은 email 필드에 대한 인덱스를 먼저 생성한다.

 

+) 카디널리티 - 고유한 값의 수

카디널리티가 높은건 중복이 적은것

 

index의 성능과 고려해야할 사항

1) 인덱스를 사용하면 효율적인 상황

- 규모가 큰 테이블

- 조회가 잦은 경우

- 삽입/삭제 작업이 자주 발생하지 않는 경우

 

2) 인덱스를 사용하면 비효율적인 상황

- 컬렉션에서 가져와야 하는 양이 많은 경우

- 조회할 일이 많이 없는 경우

- 삽입/삭제 작업이 자주 발생하는 경우 : 새로운 data를 insert 하는 경우는 index와 data를 순차적으로 정렬해야 하는 경우가 발생할 수도 있기 때문에 좋은 성능을 내지 못할 수 있어서 항상 index를 사용하는 것은 올바르지 않다.

- 데이터 중복도가 높은 경우 (ex. 성별 M, F 만 있는 경우)

 

index의 장단점

장점 : 

- 테이블의 검색 속도가 향상된다.

단점 :

- 두 번 탐색해야 한다. (인덱스 리스트 -> 컬렉션)

- 컬렉션이 수정되었을 때 인덱스도 수정되어야 한다.

- 추가 저장 공간이 필요하다.

 

트랜잭션이란?

데이터베이스의 상태를 변화시키기 위해서 수행하는 작업의 단위

데이터베이스의 상태를 변화시킨다는 것은? 간단하게 말해서 SELECT, INSERT, DELETE, UPDATE 등의 질의어(SQL)를 통해 데이터베이스에 접근하는 것을 의미한다.

 

주의해야할 점은, 작업의 단위는 질의어 한 문장이 아니라는 것이다.

트랜잭션은 사람이 설계한 논리적인 작업 단위로서, 여러 질의어들이 하나의 작업 단위일 수 있다.

 

Lock이란?

트랜잭션 처리의 순차성을 보장하기 위한 방법이다.

 

Shared Lock (공유락, s lock) : 데이터를 읽을 때 사용되어지는 락

- 공유락끼리는 동시에 접근 가능 -> 하나의 데이터를 읽는 것은 여러 사용자가 동시에 할 수 있기 때문

- s lock이 걸려있는 row에 다른 트랜잭션이 x lock을 걸 수 없다 -> 즉, 다른 트랜잭션이 읽고 있는 row를 수정하거나 삭제할 수 없다

 

Exclusive Lock (베타락, x lock) : 데이터를 변경하고자 할 때 사용되어지는 락

- 트랜잭션이 완료될 때까지 유지된다

- x lock이 걸려있는 row에는 다른 트랜잭션이 s lock과 x lock 둘 다 걸 수 없다 -> 즉, 베타락이 해제될 때까지 다른 트랜잭션(읽기 포함)은 해당 리소스에 접근할 수 없음

- `SELECT ~ FOR UPDATE` 구문으로 동시성 제어를 위하여 특정 데이터(row)에 대해 x lock을 걸 수 있다. ("데이터 수정하려고 SELECT 하는 중이야~ 다른 사람들은 데이터에 손 대지 마!")

 

요약하자면, S lock을 사용하는 쿼리끼리는 같은 row에 접근 가능하다. 반면, X lock이 걸린 row는 다른 어떠한 쿼리도 접근 불가능하다. “Shared”와 “exclusive”라는 이름의 의미와 정확히 일치한다.

 

+) SELECT ~ FOR UPDATE

https://dololak.tistory.com/446

[Database] SELECT ~ FOR UPDATE 란?

 

+) JPA에서 공유락과 베타락을 사용하는 방법?

https://velog.io/@chullll/JPA-%EC%9E%A0%EA%B8%88%EC%9D%98-%EC%A2%85%EB%A5%98

[JPA] 잠금의 종류

 

트랜잭션의 특성

(1) 원자성 (Atomicity)

트랜잭션(작업)이 데이터베이스에 모두 반영되던가, 아니면 전혀 반영되지 않아야 한다는 것이다.

 

(2) 일관성 (Consistency)

트랜잭션의 작업 처리 결과가 항상 같아야 한다는 것이다.

트랜잭션이 진행되는 동안에 데이터베이스가 변경되더라도, 변경된 데이터베이스로 트랜잭션이 진행되는 것이 아니라. 처음에 트랜잭션을 진행하기 위해 참조한 데이터베이스로 진행된다. 이렇게 함으로써 사용자는 일관성있는 데이터를 볼 수 있다.

 

(3) 독립성 (Isolation)

둘 이상의 트랜잭션이 동시에 실행되고 있을 경우, 어떤 하나의 트랜잭션이라도 다른 트랜잭션의 연산에 끼어들 수 없어야 한다는 것이다.

하나의 트랜잭션이 완료될 때까지, 다른 트랜잭션이 특정 트랜잭션의 결과를 참조할 수 없다.

 

(4) 지속성 (Durability)

트랜잭션이 성공적으로 완료되었을 경우, 결과는 영구적으로 반영되어야 한다는 것이다.

 

트랜잭션의 상태

트랜잭션 연산을 수행할 때, 5가지 상태가 존재한다.

 

1) 활성화 (Active) : 트랜잭션이 작업을 시작하여 실행중인 상태

2) 실패 (Failed) : 트랜잭션에 오류가 발생하여 실행이 중단된 상태

3) 철회 (Aborted) : 트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태

4) 부분 완료 (Partially commited) : 트랜잭션의 마지막 연산까지 실행하고 commit 요청이 들어온 직후의 상태. 최종 결과를 데이터베이스에 아직 반영하지 않은 상태

5) 완료 (Commited) : 트랜잭션이 성공적으로 종료되어 commit 연산을 실행한 후에 상태. 최종 결과를 데이터베이스에 반영한 상태

 

트랜잭션을 사용할 때 주의할 점

트랜잭션을 얻으면 빨리 해제(commit)해야 한다 -> undo 로그가 계속 쌓여서 MySQL 서버에 성능저하가 올 수 있다.

 

트랜잭션 격리 수준

격리성은 트랜잭션 수행 시 서로 끼어들지 못하는 것을 말한다고 했다.

 

복수의 병렬 트랜잭션이 있을 때,

이들은 서로 격리되어 마치 순차적으로 실행되는 것처럼 작동되어야 하고 (격리성)

여러 사용자가 같은 데이터에 접근할 수 있어야 한다. (동시성)

 

그냥 실제로 순차적으로 하면 쉽게 되겠지만 그럼 성능이 나쁠 것이다.

따라서 여러 개의 격리 수준으로 나누어 격리성을 보장한다.

 

1) SERIALIZABLE

- 트랜잭션을 순차적으로 진행시키는 것 (격리성 높다)

- 여러 트랜잭션이 동시에 같은 행에 접근할 수 없다 (동시성 낮다)

- 매우 엄격한 격리 수준으로 교착 상태가 일어날 확률도 많고 가장 성능이 떨어지는 격리 수준이다.

 

2) REPEATABLE_READ

- 하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없도록 막아주지만, 새로운 행을 추가하는 것은 막지 않는다.

- 따라서 이후에 추가된 행이 발견될 수도 있다.

- MySQL에서 기본값으로 설정되어 있다.

 

+) 어떻게하나?

버전을 두고 내 번호보다 앞선 번호만 읽는다.

 

3) READ_COMMITED

- 다른 트랜잭션이 커밋하지 않은 정보는 읽을 수 없다.

- 하지만, 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정할 수 있다.

ex. 트랜잭션 A가 수정한 행을 트랜잭션 B가 수정할 수 있다. 이 때문에 트랜잭션 A가 같은 행을 다시 읽을 때 다른 내용이 발견될 수 있다.

- 오라클 등에서 기본값으로 설정되어 있다.

 

4) READ_UNCOMMITTED

- 하나의 트랜잭션이 커밋되기 이전에 다른 트랜잭션에게 노출된다. (READ_COMMITED과 달리 다른 트랜잭션이 커밋하지 않은 정보까지 읽을 수 있다.)

- 가장 빠르지만 데이터 무결성을 위해 되도록 사용하지 않는 것이 이상적이다. (몇몇 행이 제대로 조회되지 않더라도 괜찮은 거대한 양의 데이터를 '어림잡아' 집계하는데 사용하는건 좋다)

 

격리 수준에 따라 발생하는 현상

위로 갈수록 동시성이 강해지지만 격리성은 약해지고, 아래로 갈수록 동시성은 약해지고 격리성은 강해진다.

 

SERIALIZABLE

REPEATABLE_READ - `팬텀 리드` 발생 가능

READ_COMMITED - `팬텀 리드`, `반복 가능하지 않은 조회` 발생 가능

READ_UNCOMMITTED - `팬텀 리드`, `반복 가능하지 않은 조회`, `더티 리드` 발생 가능

 

팬텀 리드 (phantom read) : 한 트랜잭션 내에서 같은 쿼리를 두 번 실행했는데 없었던 쿼리가 튀어나온다.

반복 가능하지 않은 조회 (non-repeatable read) : 한 트랜잭션 내의 같은 쿼리를 두 번 실행했는데 결과값이 다르다.

더티 리드 (dirty read) : 아직 commit되지 않은 값을 읽었는데 roll back이 발생하는 경우

 

Stored Procedure (저장 프로시저)

저장 프로시저는 쿼리문들의 집합으로, 어떤 동작을 여러 쿼리를 거쳐서 일괄적으로 처리할 때 사용한다.

 

그냥 쿼리문을 사용하면 되지 왜 저장 프로시저를 사용할까?

https://devkingdom.tistory.com/323

[MSSQL] 저장 프로시저 (Stored Procedure) 란?

 

SP(저장프로시저)의 문제점

- db 확장이 어렵다

- 문제가 생겼을 때 추적이 힘들다 (로그 확인이 힘들어서?)

 

+) 일반 쿼리문 vs 저장 프로시저

https://velog.io/@sweet_sumin/%EC%A0%80%EC%9E%A5-%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80-Stored-Procedure

저장 프로시저 (Stored Procedure)

 

Redis란?

- key, value 구조의 비정형 데이터를 저장하고 관리하기 위한 비관계형 데이터베이스 관리 시스템

- 인메모리 데이터 구조를 가진 저장소

 

레디스 특징

- key, value 구조이기 때문에 쿼리를 사용할 필요가 없다.

- 데이터를 디스크에 쓰는 구조가 아니라 메모리에서 처리하기 때문에 속도가 빠르다.

- `String`, `Lists`, `Sets`, `Sorted Sets`, `Hashes` 자료구조를 지원한다.

 

 

- Single Threaded 로, 한 번에 하나의 명령만 처리할 수 있다. 따라서 처리시간이 긴 명령어가 들어오면 그 뒤에 명령어들은 모두 앞에 있는 명령어가 처리될 때까지 대기가 필요하다. (하지만 get, set 명령어의 경우 초당 10만개 이상 처리할 수 있을만큼 빠르다.)

 

레디스 사용시 주의할 점

- 서버에 장애가 발생할 경우에 대한 운영 플랜이 꼭 필요하다. (인메모리 데이터 저장소 특성상, 서버에 장애가 발생할 경우 데이터 유실이 발생할 수 있기 때문)

- 싱글 스레드의 특성상, 한 번에 하나의 명령만 처리할 수 있다. 처리하는데 시간이 오래 걸리는 요청은 피해야 한다.

 

+) 레디스를 더 효율적으로 사용하기 위해 알아두면 좋은 개념들

- Master-Slave 형식의 데이터 이중화 구조에 대한 Redis Replication

- 분산 처리를 위한 Redis cluster

- 장애 복구 시스템 Redis Sentinel, Redis Topology, Redis Sharding, Redis Failover

- Redis Cache

 

https://seungjjun.tistory.com/246

[Redis] Redis 캐시(Cache)를 적용해 조회 성능 개선하기

 

 

https://www.wool-dev.com/backend-engineering/spring/springboot-redis-cache

SpringBoot에서 Redis 캐시를 사용하기

 

https://wildeveloperetrain.tistory.com/21

Redis란? 레디스의 기본적인 개념 (인메모리 데이터 구조 저장소)

https://career.guru99.com/ko/top-10-redis-interview-questions/

Redis 인터뷰 질문 및 답변 상위 10개(2024)