Redis [Remote Dictionary Server]는 NoSQL, 오픈소스 소프트 웨어이며 동시에 Inmemory DB입니다.
휘발성이면서 동시에 영속성을 가진 KEY-Value 형 Storage입니다.
메모리에 저장된 내용을 지속시키기 위해 파일 동기화 방법을 제공합니다.
memcached는 본질적으로 일반적인 고성능 분산 메모리 객체 캐싱 시스템이지만 원래 데이터베이스로드를 완화하여 동적 웹 응용 프로그램의 속도를 높이는 데 사용됩니다.
memcached는 간단한 휘발성 캐시 서버입니다. 값이 최대 1MB의 문자열로 제한되는 키/값 쌍을 저장할 수 있습니다. redis에 비해 제공해주는 툴이나 메모리, 지속성, 클러스터 지원 등등의 면에서 뒤처집니다.
Redis 와 memcached 의 특징을 알아 보겠습니다.
- Redis Persistence(지속성)
1. RDB(Snap shot) : 특정 순간의 상태를 통째로 메모리에 옮깁니다. 시간은 오래 걸리나 restart 가 빠릅니다.
2. AOF(Append Only File, Journal Logging) : 저장 속도가 빠릅니다. 데이터가 유실되지 않습니다. 메모리가 많이 필요합니다.
- 읽기/쓰기 속도 : 둘 다 매우 빠릅니다. 벤치 마크는 워크로드, 버전 및 기타 여러 요인에 따라 다르지만 일반적으로 redis는 memcached만큼 빠르거나 거의 빠릅니다. 나는 redis를 권장하지만 memcached가 느리기 때문에 권장하지 않습니다. 그렇지 않습니다.
- 메모리 사용량 : Redis가 더 좋습니다.
- memcached : 캐시 크기를 지정하고 항목을 삽입 할 때 데몬이이 크기보다 약간 더 빠르게 커집니다. memcached를 다시 시작하지 않고 해당 공간을 회수 할 수있는 방법은 없습니다. 모든 키가 만료되어 데이터베이스를 비울 수 있으며 구성한 RAM의 전체 청크를 계속 사용합니다.
- redis : 최대 크기를 설정하는 것은 당신에게 달려 있습니다. Redis는 더 이상 사용하지 않으며 더 이상 사용하지 않는 메모리를 다시 제공합니다.
- 나는 100,000 ~ 2KB 문자열 (~ 200MB)의 임의 문장을 둘 다에 저장했습니다. Memcached RAM 사용량이 ~ 225MB로 증가했습니다. Redis RAM 사용량이 ~ 228MB로 증가했습니다. 두 가지를 모두 플러시 한 후 redis는 ~ 29MB로 떨어지고 memcached는 ~ 225MB로 유지되었습니다. 데이터를 저장하는 방법도 비슷하지만 한 사람 만 데이터를 회수 할 수 있습니다.
- 디스크 I/O 덤핑 : 기본적으로이 작업을 수행하고 매우 구성 가능한 지속성이 있으므로 redis의 확실한 승리입니다. Memcached에는 타사 도구없이 디스크에 덤프하는 메커니즘이 없습니다.
- Scaling : 둘 이상의 인스턴스가 캐시로 필요하기 전에 두 개의 헤드 룸을 제공합니다. Redis에는 memcached가 제공하지 않는 기능을 뛰어 넘는 툴(redis-sentinel)이 포함되어 있습니다.
- 파이프 라이닝 : 실행할 redis 명령이 많은 경우 파이프 라이닝을 사용하여 한번에 하나씩이 아니라 한 번에 redis로 보낼 수 있습니다. 여러 명령을 버퍼링하고 한 번에 모두 실행할 수 있으므로 모든 명령에 대한 모든 응답으로 단일 응답으로 응답 할 수 있습니다.
- 펍/서브 : redis가 고속 메시지 브로드 캐스터로 작동 할 수 있도록합니다. 이를통해 단일 클라이언트는 채널에 연결된 다른 많은 클라이언트에게 메시지를 게시 할 수 있습니다. RabbitMQ와 같은 전용 메시지 브로커는 특정 영역에 이점이 있을 수 있지만 동일한 서버가 영구적 인 내구성이 있는 대기열과 pub/sub 워크로드에 필요한 데이터 구조를 제공할 수 있습니다.
- 해시
해시는 키 값 저장소 내의 키 값 저장소와 비슷합니다. 문자열 필드와 문자열 값 사이를 매핑합니다. 해시를 사용하는 필드-> 값 맵은 일반 문자열을 사용하는 키-> 값 맵보다 약간 공간 효율적입니다.
해시는 네임 스페이스로 사용하거나 많은 키를 논리적으로 그룹화하련느 경우에 유용합니다. 해시를 사용하면 모든 멤버를 효율적으로 잡고, 모든 멤버를 함께 만료하고, 모든 멤버를 함께 삭제할 수 있습니다. 그룹화해야 여러 키/값 쌍이 있는 사용 사례에 적합합니다.
예시로는 WAS간 사용자 프로필을 저장하는 것 입니다.
사용자 ID를 키로 저장 한 redis 해시는 사용자에 대한 데이터를 단일 키로 유지하면서 필요한 만큼의 비트를 저장할 수 있습니다.
프로필을 문자열로 직렬화 하는 대신 해시를 사용하면 한 응용프로그램이 다른 응용프로그램의 변경사항을 무시하지 않아도 다른 WAS 에서 사용자 프로그램이 사용자 프로필 데이터의 다른 필드를 읽거나 쓸 수 있다는 장점이 있습니다. (부실한 직렬화를 수행할 경우 발생한 데이터 Read/Write).
- memcached의 장점이라 하면 단순하며 안정적입니다. redis보다 약간 더 빠른 유스 케이스도 있습니다.
그러나 미래의 발전에 많은 의미가 있다고 생각하지는 않습니다.
이미 memcached가 요구사항을 충족시키고 있지 않고 memcached이상으로 확장해야 하거나 추가 기능이 필요하지 않다면 memcached를 사용하는 것도 나쁘지 않은 선택이라 생각합니다.
참고
레디스와 맴캐시 차이 , https://www.it-swarm.dev/ko/caching/memcached-%EB%8C%80-redis/1067241005/
맴캐시란? , https://memcached.org/about
'used-market-server Project' 카테고리의 다른 글
서블릿 컨테이너 톰캣의 session 저장 방식 (0) | 2020.07.24 |
---|---|
spring boot 환경에서 session 저장하기 (0) | 2020.07.24 |
세션 클러스터링 이란? (0) | 2020.06.25 |
웹서버 , WAS 비교 (0) | 2020.06.20 |
Stateful, Stateless (웹서버 통신 방식) (2) | 2020.06.19 |