티스토리 뷰
MySQL과 Redis
인메모리 DB 와 디스크 기반 DB
DBMS ( Data Base Management System )는 데이터를 저장 관리해주는 시스템을 얘기한다. 이 DBMS의 다양한 분류기준 중 데이터를 저장하는 위치에 따른 분류로 인메모리와 디스크로 나눌 수 있다.
인메모리는 RAM 이라고 부르는 휘발성 저장장치에 저장한고 반대로 디스크 기반인 경우 하드 디스크 혹은 SSD 라고 부르는 영속저장 장치에 저장된다.
기본적으로 MySQL의 경우 디스크에 저장되는 디스크 기반 데이터베이스이고 Redis의 경우 메모리(주 기억장치)에 저장되는 인메모리 데이터 베이스에 한 종류이다. 때문에 종류 별 특징을 아는 것은 중요하다.
인메모리 VS 디스크
기본적으로 인메모리 데이터베이스는 디스크(HDD/SSD)에 비해 메모리(RAM)이 가격이 비싸다. 또한 메모리의 특성 때문에 전력이 차단 되는 경우 데이터가 휘발되어 사라진다. 물론 AWS Elastic Chache와 같은 서비스를 이용 하거나 영구 저장 장치에 먼저 백업하는 방법으로 커버 할 수 있지만 기본적으로는 휘발성을 띈다.
사실 위에 내용만으로는 인메모리 데이터베이스의 단점만 있는것 처럼 보인다. 하지만 인메모리 데이터베이스는 디스크기반 데이터베이스에 비해 높은 I/O 성능을 가진다. 그도 그럴것이 인메모리 데이터베이스의 경우 메모리에 쓰고•읽는 작업을 하지만 디스크 기반 데이터베이스의 경우 메모리가 아닌 디스크에 쓰고 읽는 디스크 I/O가 발생하기 때문에 상대적으로 느릴 수 밖에 없다.
디스크 I/O
하드 디스크 (HDD)의 I/O
하드 디스크는 전통적인 영속적 저장 매체이다. 하드 디스크에 있는 데이터를 읽고•쓰는 것에는 여러가지 문제점이 있다. 기본적으로 하드디스크는 헤드가 가리키는 위치에 읽고 쓰기위해 원판을 물리적으로 회전시킨다. 때문에 데이터를 읽기 위해서는 원하는 데이터가 있는 위치까지 원판을 돌려 읽거나 비어있는 공간을 찾아 원판을 회전시켜 쓴다. 기본적으로 전기적 신호를 통해 데이터를 읽고•쓰는 메모리에 비해 느릴 수 밖에 없다.
솔리드 스테이드 드라이브 (SSD)의 I/O
하드 디스크와 달리 SSD의 경우 물리적 회전이 필요한 원판과 헤더가 없다. 메모리와 같이 전기적 신호를 통해 읽고 쓸 수 있다. 덕분에 데이터 탐색 시간(Seek Time)이 줄어들어 HDD에 비해 읽기 성능이 대폭 향상되었다.
하지만 SSD에도 문제는 존재한다. 기본적으로 SSD는 페이지 단위로 읽고 쓸 수 있어 데이터의 크기 보다 더 큰 크기의 페이지를 읽어야 하거나 SSD의 경우 비어 있는 공간에만 쓰는 것이 가능하기 때문에 쓰기 위해서는 데이터를 삭제해야 한다. 즉, 덮어쓰기가 안된다.
때문에 쓸 수 있는 공간을 찾기위해 페이지를 이동하거나 삭제하는 작업이 추가로 필요할 수 있다.
Tip
SSD는 페이지 < 블록 < 플레인 < 다이 의 크기로 데이터를 관리한다.
또한 쓰거나 읽는 것은 페이지 단위로도 가능하지만 삭제는 블록단위로만 가능하다.
특징 | 인메모리 | 디스크 |
---|---|---|
가격 | 💰 비쌈 | 💰저렴함 |
지속성 | 휘발성 | 영속성 |
속도 | 빠름 | 느림 |
MySQL과 Redis는 각각 디스크와 인메모리 데이터베이스이다. 때문에 디스크 I/O가 아닌 인메모리 데이터베이스가 더 높은 성능을 보장하지만 많은 데이터를 저장하기에는 저장 공간이 비싸고 휘발성을 띄고 있어 영구 저장하는 목적으로 사용하기에는 어렵다. 때문에 액세스 패턴에 맞는 장점을 가진 데이터 베이스를 선택하는것이 필요하다.
Key-Value 와 로우형 데이터베이스
MySQL과 Redis는 저장 형태도 다르다. MySQL의 경우 로우형 DBMS 이며 Redis 는 Key-Value형 데이터베이스다.
로우형 데이터베이스
로우형 데이터베이스에는 전통적인 RDBMS 가 있다. 데이터를 로우로 하나의 블록에 저장하는 방식을 가지고 있다. 위에서 디스크 I/O에는 최소 작업 단위가 존재한다고 했는데 이러한 최소 작업 단위에 로우 전체를 저장하는 방식이 로우형 데이터베이스이다.
이렇게 하나의 블록에 하나의 로우를 저장하기 때문에 한 번의 디스크 I/O로 하나의 로우를 가지고 올 수 있다는 특징을 가진다. 다만 필요 없는 필드 역시 조회해야 한다는 것이 부담으로 작용할 수도 있다.
Key-Value 형 데이터베이스
Redis는 Key-Value 기반의 데이터베이스이다. 해시 함수와 해시 테이블을 사용해 키를 관리하기 때문에 상당히 빠른 탐색속도를 가지고 있다.
MySQL과 Redis 모두 각자 역할에 맞는 데이터 저장 형태를 가진다. 만약 MySQL이 컬럼형을 선택했다면 Join 을 통해 여러 테이블을 참조하게 되면 너무 많은 디스크의 페이지(블록)를 탐색해야 했을 것이다. 혹은 Redis가 로우형 데이터베이스를 선택했다면 지금과 같은 속도의 검색은 불가능 했을 것이다. 두 데이터 베이스 모두 용도에 맞는 형태의 데이터 구조를 선택했다고 볼 수 있다.
참조
'DataBase' 카테고리의 다른 글
MySQL VS MongoDB 비교해보자! (0) | 2022.11.07 |
---|---|
인덱스 키의 빈번한 Update로 발생할 수 있는 오버헤드 (0) | 2022.10.13 |
Nested (Loop) Join 과 Hash Join (0) | 2022.08.23 |
CAP 정리란? (0) | 2022.08.20 |
샤딩(Sharding)이란? (0) | 2022.07.27 |
- Total
- Today
- Yesterday
- Object Pool
- 외부 단편화
- 컴포짓 패턴
- pool
- 동적 디스패치
- Session
- SpringBoot 2.2
- 클린 아키텍처
- 뾰족함
- 수평 분할
- ATDD
- 내부 단편화
- 메모리 파편화
- 동적 타입 언어
- 육각형 아키텍처
- 수직 분할
- RestAssured
- pass by value
- Memory Fragmentation
- pass by reference
- 세션 불일치
- java
- Clean Architecture
- 정적 타입 언어
- OOP
- 객체 풀
- 장애 해결기
- Sticky Session
- multimap
- 메모리 단편화
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |