본문 바로가기

In-Memory NoSQL DBMS Redis 본문

Dev

In-Memory NoSQL DBMS Redis

겨울바람_ 2023. 6. 18. 02:03

Redis (Remote Dictionary Server)

https://en.wikipedia.org/wiki/Redis

Remote : 원격 접속 혹은 원격 서비스를 지원하는 것을 일컫는다. Redis 는 기본적으로 로컬 환경에서 실행되지만, 해당 기능을 통해 원격 서버에 있는 Redis 인스턴스에 접속하여 데이터를 읽고 쓰는 것이 가능하다.

 

Dictionary : Key-Value 구조로 데이터를 저장한다는 것을 의미한다. 이로 인해 여타 RDBMS 처럼 쿼리 연산을 지원하지 않지만, 단순한 데이터 저장 구조 덕분에 빠른 데이터 읽기와 쓰기가 가능하다.

 

In-Memory : Redis 는 여타 데이터베이스처럼 디스크(SSD)에서 데이터를 처리하는 방식이 아닌, 메모리에서 데이터를 처리하기 때문에 디스크에서 데이터를 다루는 데이터베이스들과 비교했을 때 우월한 작업 속도를 가진다.

 

위와 같은 특징들 덕분에, Redis 는 백엔드 개발자에게 있어서 굉장히 친숙한 NoSQL 데이터베이스 혹은 Cache 로 발돋움하게 되었다. 


Redis Data Structure

Redis 는 데이터를 효율적으로 저장하기 위해 다양한 자료구조를 제공하고 있다. Redis 를 더 효과적으로 사용하기 위해서 Redis 에서 제공하는 자료구조에 대해 알아보자.

Strings

일반적인 문자열 형태로 최대 512MB 까지 저장할 수 있도록 지원하고 있다. 

https://redis.com

Bitmaps

일반적인 문자열 형태로 저장하던 Strings 와는 다르게 저장 공간을 절약하기 위해 0과 1의 비트 단위로 데이터를 저장한다. 일일 접속 방문자 수 혹은 좋아요 등과 같이 대용량 누적 단순 데이터를 저장하는데 효율적인 저장방식이라고 생각된다.

https://linuxhint.com/redis-bitop/

Lists

배열 형식의 자료구조로 데이터를 순서대로 저장한다. Linked List 자료 구조와 굉장히 유사한 방식으로 데이터를 관리한다. 배열의 처음과 끝 (Head & Tail) 에 데이터를 추가, 삭제, 조회하는 것은 O(1) 의 속도를 갖지만, 배열 중간의 데이터를 조회할 때는 O(N) 의 속도를 갖는다. 해당 자료구조는 FIFO 방식으로 데이터를 저장하는 것이 효율적이라고 생각이 되기 때문에 Message Queue 로 사용할 때 적합한 자료구조라고 생각된다.

https://redis.com

Hashes

hash 는 field-value 형태로 구조화된 자료구조이며, Key 하위에 SubKey 를 활용해 추가적인 Value 를 삽입하는 것으로 Hash Table 을 형성한다. hash 자료구조를 활용하여 기본적인 객체를 표현할 수 있다. hash 자료구조는 내부적으로 hash 함수를 사용하여 SubKey-Value 쌍을 Hash Table 에 저장하기 때문에, 평균적으로 O(1) 의 속도로 조회 및 삽입, 삭제 작업을 수행할 수 있다.  

https://redis.com

Sets

Java 의 HashSet 과 유사한 형태로, 중복된 데이터를 저장하지 않기 위해 사용하는 자료구조이다. 데이터를 저장할 때 순서를 고려하지 않으며, 중복된 데이터를 여러 번 저장할 경우 가장 마지막에 저장한 데이터가 저장된다. 순서를 고려하지 않는다는 단점을 보완하기 위해 나온 자료구조가 아래에서 설명할 Sorted Sets 이다.

https://redis.com

Sorted Sets

Set 에 Score 라는 필드가 추가된 형태로, Java 의 TreeSet, Sorted Set 과는 다르게 Score 라는 필드를 사용해 데이터의 순서를 관리한다. 데이터가 Sorted Set 에 저장될 때 Score 순으로 정렬되어 저장되며, 오름차순으로 기본 정렬된다. Value 의 경우 Set 과 동일하게 중복된 값을 저장하는 것이 불가능하지만, Score 의 경우 중복된 값으로 저장해도 기존의 데이터에 중첩되지는 않는다. 만약 Score 가 동일할 경우, 사전 순으로 정렬된다. 

https://meetup.nhncloud.com/posts/224

 HyperLogLogs

대용량의 데이터를 Dump 할 때 사용한다. 중복되지 않는 대용량 데이터를 Count 할 때 주로 사용하며, Set 과 비슷하지만 저장되는 모든 값이 12KB 로 고정되어 있기 때문에 저장되는 용량이 매우 작다. HyperLogLog 로 저장된 데이터는 다시 확인하는 것이 불가능하다.


Cache

Redis 사용하는 여러가지의 목적 중 가장 대표적인 Cache 에 대해서 알아보도록 하자. 위에 기술한 내용 중 Redis 는 메모리에서 데이터를 처리하기 때문에 다른 데이터베이스에 비해 우월한 작업 속도를 가진다는 내용이 있다. 디스크에서 데이터를 관리하는 데이터베이스의 경우 안전성 측면에서는 장점을 지니지만, 매 트랜잭션마다 디스크에 접근해야 하기 때문에 속도와 서버에 가해지는 부하 측면에서 불이익을 가진다.

 

이러한 이유 때문에, 데이터베이스에 자주 요청되지만 수정될 일이 적은 데이터를 미리 특정 공간에 저장해두는 것으로 해당 데이터에 대한 요청이 왔을 때 디스크까지 갈 필요없이 해당 공간에서 데이터를 즉각적으로 제공하는 것을 Cache 라고 한다. 

 

메모리에서 데이터를 관리하는 Redis 의 특성상 데이터 전달 및 처리에 있어서 우월한 접근 속도를 가지기 때문에, Cache 서버로 사용되기 적합한 툴이라고 볼 수 있다. 하지만 메모리의 특성 상, 디스크에 비해 적은 용량을 가지고 있어서 무차별적으로 데이터를 저장한다면 용량 부족이 발생할 수 있기 때문에 적절한 Cache 전략이 필요하다.

 

또한 원하는 데이터가 Cache Store 에 저장되어 있다면 Cache Hit, 즉 Cache Store 에서 빠르게 데이터를 가져올 수 있지만 Cache Store 에 원하는 데이터가 없는 Cache Miss 가 발생할 경우 DB 에서 데이터를 가져와야 하기 때문에 Cache 를 사용하지 않을 때보다 느려지는 경우가 존재한다. 

https://rocketcdn.me/what-is-a-cache-hit-ratio/


Data Consistency

데이터 정합성

Cache 를 사용하게 될 경우 필연적으로 마주치는 문제가 바로 데이터 정합성 문제이다. Cache Store 에 저장되어 있는 데이터와 DB 에 저장되어 있는 데이터 간의 정보 불일치를 일컫는 말로 DB 와 Cache Store 두 가지의 데이터 저장소를 이용하기 때문에 발생하는 문제다. 

 

데이터 정합성 문제를 해결하기 위해서 적절한 Read Cache Strategy 와 Write Cache Strategy 을 통해, Cache Store 와 DB 간의 데이터 불일치 문제를 예방하면서도 Cache 를 사용하는 이유인 빠른 속도를 유지해야 한다. 다음 포스트에서는 이를 위한 Cache Strategy 에 대해 알아보고자 한다. 


결론

이번 포스트의 내용을 Redis 와 Cache 로 작성하게 된 가장 큰 이유는 필자의 토이 프로젝트에 Redis 를 사용하여 Cache 전략을 적용했기 때문이다. Redis 에 대한 약간의 지식은 있었지만, 해당 기술을 더 효율적으로 사용하기 위해서는 그 기술에 대한 깊은 이해가 필수적이라고 생각하기 때문에 이번 포스팅을 기회로 Redis 에 대해 더 조사해보고자 마음 먹었고, 이번 포스팅 덕분에 전보다 확실히 Redis 에 대한 이해도가 향상된 것 같다. 이번 포스팅의 메인 주제는 Redis 의 자료구조와 Cache 전략에 대한 것이었는데, Redis 는 각 자료구조별로 다른 Command 를 제공해주고 있으니 해당 Command 에 대한 조사도 필수적으로 이루어져야 할 것 같다. 

 

이번 글은 다른 기술 블로그를 보고 공부했던 내용들을 정리한 것이다. 필자의 글보다 더 잘 정리해두셨으니 꼭 한 번 참고해보길 바란다.

 

위에서 기술했던 내용과 동일하게 필자의 글에는 잘못된 정보가 존재할 수 있으며, 그에 대한 피드백은 언제나 환영합니다.

 

참고 블로그 

https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EC%BA%90%EC%8B%9CCache-%EC%84%A4%EA%B3%84-%EC%A0%84%EB%9E%B5-%EC%A7%80%EC%B9%A8-%EC%B4%9D%EC%A0%95%EB%A6%AC
https://velog.io/@kkimbj18/%EB%A0%88%EB%94%94%EC%8A%A4Redis-%ED%8C%8C%ED%97%A4%EC%B9%98%EA%B8%B0-2-%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0
https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%83%80%EC%9E%85Collection-%EC%A2%85%EB%A5%98-%EC%A0%95%EB%A6%AC

'Dev' 카테고리의 다른 글

HTTP  (1) 2024.02.24
Transaction  (0) 2024.02.20
Spring Security Session 과 RestAPI  (0) 2023.08.17
JVM Runtime Data Area Structure  (1) 2023.05.08
JWT를 사용하여 웹 사이트 공격에 대비하기 (with.Spring Security)  (0) 2023.04.29
Comments