[DB] Redis(Remote dictionary server)란?
Redis(Remote dictionary server)란?
- Remote -> 외부, dictionary -> HashMap (Key - Value), server -> 서버
- Database, Cache, Message borker
- In-memory Data Structure Store
- Supports rich data structure
Redis(레디스)는 REmote DIctionary Server의 약자로 오픈소스DBMS입니다. In-memory 데이터 저장소이며, Key-Value기반의 NoSQL DBMS입니다. 보통 DB, Cache(캐시), 메시지 브로커 등의 용도로 사용합니다.
Redis를 효율적으로 쓰기 위해선 Cache에 관해 잘 알아야합니다.
Cache는 나중의 요청에 대한 결과를 미리 저장했다가 빠르게 사용하는 것입니다. 어디에 저장하는 것이 가장 빠를까요??
기본적으로 메모리는 계층구조를 이룹니다.
위로 갈수록 빠르고 비싸고 밑으로 갈수록 느리고 저렴한 저장소라고 생각하면 됩니다.
기본적으로 데이터는 컴퓨터가 꺼져도 저장이되어야 하기 떄문에 Secondary Memory(SSD,HDD 등)에 저장이 되는데, 기술이 발달하고 하드웨어들이 커지다보니깐 Main Memory에 저장하고 쉽게 접근하면 어떨까? 하는 개념으로 나온게 Redis입니다.
Redis는 기존 관계형 데이터베이스(Oracle, MySQL) 보다 훨씬 빠른데 그 이유는 메모리 접근이 디스크 접근보다 빠르기 때문입니다. * Secondary Memory를 디스크 영역이라고 보면 됩니다.
즉, Database보다 더 빠른 Memory에 더 자주 접근하고 덜 자주 바뀌는 데이터를 저장할때 적합합니다.
Redis와 다른 In-memory 데이터베이스(ex, memcached)와의 가장 큰 차이점은 다양한 자료구조를 지원한다는 것입니다.
레디스는 기본적으로 String, Bitmap, Hash, List, Set, Sorted Set을 제공합니다.
레디스에서 이렇게 다양한 자료구조를 지원하는것이 중요한 이유는 무엇일까요?
바로 개발의 편의성과 난이도 때문입니다.
예를 들어,
예를 들어 실시간 랭킹 서버를 구현할 때 관계형 DBMS를 이용한다면 DB에 데이터를 저장하고, 저장된 SCORE 값으로 정렬하여 다시 읽어오는 과정이 필요합니다. 이 때 레디스의 Sorted-Set을 이용하면 더 빠르고 간단하겠죠?
레디스는 트랜잭션의 문제도 해결해 줄 수 있습니다. 싱글 스레드로 동작하는 서버의 모든 자료구조는 atomic 하기 때문에, race condition을 피해 데이터의 정합성을 보장하기 쉽습니다.
즉, 외부의 Collections을 잘 이용하는 것만으로 개발 시간 단축이 가능하고, 생각하지 못한 여러가지 문제를 줄여줄 수 있으므로 개발자는 비즈니스 로직에 집중할 수 있다는 큰 장점이 존재합니다.
Java와 Redis를 자료구조를 비교해보자.
private final Map<String, Object> hyungilHashMap = new HashMap<>();위 코드는 HashMap에 db를 사용해서 저장하는 In-memory 데이터베이스 입니다.. 하지만 서버가 여러대일 경우에 서버마다 다른 데이터를 가지고 있기 때문에 Consistency의 문제가 발생할 수 있습니다,
세션같은 경우 자바 객체로 저장하면 다른 서버에서는 해당 세션이 없기 때문에 문제가 발생할 수 있습니다.
또한 Multi-Thread 환경에서는 Race-Condition이 발생할 수 있습니다.
Race-Condition이란? 둘 이상의 입력 또는 조작의 타이밍이나 순서 등이 결과값에 영향을 줄 수 있는 상태를 말합니다. 입력 변화의 타이밍이나 순서가 예상과 다르게 작동하면 정상적인 결과가 나오지 않게 될 위험이 있는데 이를 경쟁 위험이라고 합니다.. 여러개의 Thread가 경합하면 Context Switching에 따라 원하는 결과가 발생할 수 있습니다.
이 글을 읽어보시면 memcached와 redis의 차이점에 관해 자세하게 읽어보실 수 있습니다.
Race-Condition을 해결하기 위해 Redis의 자료구조는 Atomic Critical Section에 대한 동기화를 제공합니다.
Critical Section은 동시에 여러 프로세스가 접근하면 안되는 부분이라고 생각하면 됩니다.
그래서 여러 Transaction들이 Read/Write를 동기화하면서 원치않느 결과를 막아주는 기본적인 구현이 Redis는 적용되어있습니다.
Spring에선 Redis API를 지원해줍니다.
우린 의존성만 추가해서 편리하게 Redis를 사용할 수 있겠죠?
그러면 Redis를 어디서 쓸까요?
- 여러 서버에서 같은 데이터를 공유할 때
- Single Server라면? Atomic한 자료구조라던지 Cache를 쓸 때
- 스프링에서 Redis API를 지원해주기 때문에 스프링 프레임워크와 관련한 프로젝트를 진행할 때
를 고려해볼 수 있겠네요.
다음글 : Redis는 왜 Single Threaded로 동작할까?
참고 문헌 :
https://techxplod.com/memory-hierarchy/
https://meetup.toast.com/posts/224
https://www.youtube.com/watch?v=Gimv7hroM8A&t=278s