[DB] 데이터베이스를 지탱하는 기술 Chapter 2

데이터베이스를 사용하는 이유

- 대용량 데이터 처리

- 일반적인 자료구조로는 인메모리로만 사용 가능

- 디스크를 이용할 수 있어야 한다.

- 빠른 탐색이 가능해야 한다.

- 인덱스 (BTree 자료구조)

- 장애 발생 시 데이터 백업 및 복구

- 데이터가 사라지지 않도록 해야 한다.

- 데이터의 무결성을 위해 '트랜잭션' 개념 적용

- 해당 솔루션을 제공

- Redis의 경우 Replication 및 RDB / AOF 옵션

- 병렬성 제어가 어려움

- Lock 개념이 들어감.

- 성능과 상황에 따라 Table Lock / Row Lock 등을 사용할 수 있도록 해당 기능을 제공해 줌

- InnoDB의 경우 Isolation Level 옵션 등

NoSQL

- 기존 DB에서 충분한 성능이 나오지 않거나, 여러 서버를 구축하기 어려운 경우에 일부 기능을 삭제함으로써 이를 실현하는 것을 목표로 한다.

- 기존 DB에 비해 안정성이 떨어지는 것이 문제되고 있어서 기존 DB를 확장하여 이 문제를 해결하려는 노력도 보인다.

고정 길이 파일

- 해당 Row의 길이를 미리 고정하고 접근한다. 

- 예를 들면 유저 ID * 100 바이트 위치가 실제 해당 유저의 데이터 위치이다.

- 빠르게 데이터 처리가 가능하다.

- 할당된 데이터를 모두 쓰지 않는 경우 메모리 낭비가 발생한다. 

- 마치 운영체제에서 페이징 처리 시 내부 단편화가 일어나는 것과 같다.

인덱스

- BTree 를 기본으로 구현함

- Entry가 [Key, Byte Offset] 으로 구성됨

- 책의 목차 페이지와 비슷하다.

- 목차의 Entry는 [Key, Page] 로 구성되어 있다. 이를 이용

- 각각의 key마다 메모리 상의 실제 위치를 기록한다. 그래서 key 검색하면 곧바로 해당 메모리를 참조한다.

- key와 offset을 unsigned int로 하면 4byte, 약 40억까지 취급할 수 있어서 대부분 이것으로 충분하다.

해시 인덱스

- 인덱스만으로는 위에서 언급한 '고정 길이 파일' 방식과의 차이가 [Key, Byte Offset] 뿐이다. Key는 숫자, 문자열, 날짜/시간 등 여러가지가 있을 수 있으므로, 범용성을 생각하면 Hash를 이용해야 한다. 이런 방식을 해시 인덱스라 한다.

- Hash는 데이터의 양과 무관하게 동작하는 알고리즘이다. 시간복잡도는 O(1)이라 볼 수 있다.

- 하지만 데이터의 양이 많아질 수록 Hash Collision이 자주 발생할테니 완벽하게 무관하다고 할 수는 없다.

- 만능이 아니다.

- Hash값은 지정한 키 값과 같은 것만 찾을 수 있다. 그래서 범위 탐색이 불가능하다.

- Ex) 가격이 10000원 이하

- Ex) 제목이 "Final"로 시작

- 정렬에 있어서도 Hash는 도움이 되지 않는다.

- Ex) 가격이 싼 순서대로 정렬

- 참조 / 업데이트가 빠른 것이 장점이나 모든 문제를 해결하지는 못한다.

- 그래서 B+ Tree를 사용한다.