요약 (TL; DR)

2017 년 6 월 3 일 업데이트

Redis는 memcached보다 더 강력하고 대중적이며 더 잘 지원됩니다. Memcached는 Redis가 할 수있는 일 중 일부만 수행 할 수 있습니다. Redis는 기능이 겹치는 경우에도 더 좋습니다.

새로운 것은 Redis를 사용하십시오.

Memcached 및 Redis : 직접 비교

두 도구는 캐시로 유용한 강력하고 빠른 인 메모리 데이터 저장소입니다. 둘 다 데이터베이스 결과, HTML 조각 또는 생성하는 데 비용이 많이 드는 것을 캐싱하여 응용 프로그램 속도를 높일 수 있습니다.

고려해야 할 사항

같은 것에 사용될 때, 원래 질문의 “고려할 점”을 사용하여 비교하는 방법은 다음과 같습니다.

• 읽기 / 쓰기 속도 : 둘 다 매우 빠릅니다. 벤치 마크는 워크로드, 버전 및 기타 여러 요인에 따라 다르지만 일반적으로 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에는 타사 도구없이 디스크에 덤프하는 메커니즘이 없습니다.
• 스케일링 : 둘 이상의 인스턴스가 캐시로 필요하기 전에 헤드 룸이 많이 있습니다. Redis에는 memcached가 제공하지 않는 기능을 뛰어 넘는 툴이 포함되어 있습니다.

memcached

Memcached는 간단한 휘발성 캐시 서버입니다. 값이 최대 1MB의 문자열로 제한되는 키 / 값 쌍을 저장할 수 있습니다.

이것에 능숙하지만 그것이 전부입니다. 매우 빠른 속도로 키를 사용하여 이러한 값에 액세스 할 수 있으며, 종종 사용 가능한 네트워크 또는 메모리 대역폭을 포화 상태로 만듭니다.

memcached를 다시 시작하면 데이터가 사라집니다. 이것은 캐시에 좋습니다. 거기에 중요한 것을 저장해서는 안됩니다.

고성능 또는 고 가용성이 필요한 경우 타사 도구, 제품 및 서비스를 사용할 수 있습니다.

레디 스

Redis는 memcached와 동일한 작업을 수행하고 더 잘 수행 할 수 있습니다.

Redis는 캐시 역할도 할 수 있습니다. 키 / 값 쌍도 저장할 수 있습니다. redis에서는 최대 512MB까지 가능합니다.

지속성을 끌 수 있으며 재시작시에도 데이터가 손실됩니다. 캐시를 다시 시작하기를 원하는 경우에도 캐시를 수행 할 수 있습니다. 사실, 이것이 기본값입니다.

네트워크 나 메모리 대역폭에 의해 제한되는 초고속이기도합니다.

redis / memcached 인스턴스 중 하나가 워크로드에 적합한 성능이 아닌 경우 redis가 확실한 선택입니다. Redis에는 클러스터 지원이 포함되어 있으며 ” 기본적으로 ” 고 가용성 도구 ( redis-sentinel )가 제공됩니다. 지난 몇 년 동안 redis는 타사 툴링의 확실한 리더로 부상했습니다. Redis Labs, Amazon 및 기타 회사와 같은 회사는 많은 유용한 redis 도구 및 서비스를 제공합니다. redis 주변의 생태계는 훨씬 더 큽니다. 대규모 배포의 수는 이제 memcached보다 클 수 있습니다.

레디 스 수퍼 셋

Redis는 단순한 캐시 이상입니다. 인 메모리 데이터 구조 서버입니다. 아래에서 Redis가 memcached와 같은 간단한 키 / 값 캐시를 넘어서 할 수있는 일에 대한 간단한 개요를 볼 수 있습니다. redis의 기능은 대부분 memcached가 할 수없는 기능입니다.

선적 서류 비치

Redis는 memcached보다 문서화되어 있습니다. 이것은 주관적 일 수 있지만, 점점 더 사실 인 것 같습니다.

redis.io 는 쉽게 탐색 할 수있는 환상적인 리소스입니다. 브라우저에서 redis 를 시도 하고 문서의 각 명령으로 대화 형 예제를 제공 할 수도 있습니다.

Redis에 대해 memcached보다 2 배 많은 스택 오버플로 결과가 있습니다. Google 검색 결과의 2 배 더 많은 언어로 더 쉽게 접근 할 수있는 예제. 보다 적극적인 개발. 보다 적극적인 고객 개발. 이러한 측정은 개별적으로 의미있는 것은 아니지만, redis를 지원하고 문서화하는 것이 훨씬 더 최신의 명확한 그림을 그립니다.

고집

기본적으로 redis는 스냅 샷이라는 메커니즘을 사용하여 데이터를 디스크에 유지합니다. 사용 가능한 RAM이 충분한 경우 성능 저하없이 거의 모든 데이터를 디스크에 쓸 수 있습니다. 거의 무료입니다!

스냅 샷 모드에서는 갑작스러운 충돌로 인해 소량의 데이터가 손실 될 수 있습니다. 데이터를 잃어 버릴 염려가 없어도 걱정하지 마십시오. redis는 AOF (Append Only File) 모드를 사용하여 등을 가지고 있습니다. 이 지속성 모드에서 데이터는 기록 될 때 디스크에 동기화 될 수 있습니다. 이렇게하면 최대 쓰기 처리량을 줄일 수 있지만 디스크 쓰기 속도는 빨라지지만 여전히 빠릅니다.

필요한 경우 지속성을 미세 조정하기위한 많은 구성 옵션이 있지만 기본값은 매우 합리적입니다. 이 옵션을 사용하면 데이터를 저장하기위한 안전하고 중복 된 장소로 Redis를 쉽게 설정할 수 있습니다. 그것은이다 실제 데이터베이스.

많은 데이터 유형

Memcached는 문자열로 제한되지만 Redis는 다양한 데이터 유형을 처리 할 수있는 데이터 구조 서버입니다. 또한 해당 데이터 유형을 최대한 활용하는 데 필요한 명령도 제공합니다.

문자열 ( 명령 )

최대 512MB 크기의 간단한 텍스트 또는 이진 값입니다. memcached 문자열은 1MB로 제한되지만 이것은 redis 및 memcached 공유의 유일한 데이터 유형입니다.

Redis는 비트 단위 작업, 비트 수준 조작, 부동 소수점 증분 / 감소 지원, 범위 쿼리 및 다중 키 작업에 대한 명령을 제공하여이 데이터 유형을 활용하기위한 더 많은 도구를 제공합니다. Memcached는이를 지원하지 않습니다.

문자열은 모든 종류의 사용 사례에 유용하므로 memcached는이 데이터 유형에만 유용합니다.

해시 ( 명령 )

해시는 키 값 저장소 내의 키 값 저장소와 비슷합니다. 문자열 필드와 문자열 값 사이를 매핑합니다. 해시를 사용하는 필드-> 값 맵은 일반 문자열을 사용하는 키-> 값 맵보다 약간 공간 효율적입니다.

해시는 네임 스페이스로 사용하거나 많은 키를 논리적으로 그룹화하려는 경우에 유용합니다. 해시를 사용하면 모든 멤버를 효율적으로 잡고, 모든 멤버를 함께 만료하고, 모든 멤버를 함께 삭제할 수 있습니다. 그룹화해야하는 여러 키 / 값 쌍이있는 사용 사례에 적합합니다.

해시 사용의 한 예는 응용 프로그램간에 사용자 프로필을 저장하는 것입니다. 사용자 ID를 키로 저장 한 redis 해시는 사용자에 대한 데이터를 단일 키로 유지하면서 필요한만큼의 비트를 저장할 수 있습니다. 프로필을 문자열로 직렬화하는 대신 해시를 사용하면 한 응용 프로그램이 다른 응용 프로그램의 변경 사항을 무시하지 않아도 다른 응용 프로그램이 사용자 프로필 내에서 다른 필드를 읽거나 쓸 수 있다는 장점이 있습니다 (부실한 직렬화를 수행 할 경우 발생할 수 있음) 데이터).

목록 ( 명령 )

Redis 목록은 정렬 된 문자열 모음입니다. 목록의 상단 또는 하단 (일명 왼쪽 또는 오른쪽)에서 값을 삽입, 읽거나 제거하는 데 최적화되어 있습니다.

Redis는 항목 푸시 / 팝, 목록 사이 푸시 / 팝, 목록 자르기, 범위 쿼리 수행 등을 포함하여 목록을 활용하기위한 많은 명령 을 제공합니다 .

목록은 내구성이 뛰어나고 원자적인 대기열을 만듭니다. 이들은 작업 대기열, 로그, 버퍼 및 기타 여러 유스 케이스에 적합합니다.

세트 ( 명령 )

세트는 순서없는 고유 값 모음입니다. 값이 세트에 있는지 신속하게 확인하고 값을 빠르게 추가 / 제거하고 다른 세트와의 겹침을 측정 할 수 있도록 최적화되었습니다.

액세스 제어 목록, 고유 한 방문자 추적기 및 기타 여러 가지에 유용합니다. 대부분의 프로그래밍 언어에는 비슷한 것이 있습니다 (보통 Set이라고 함). 이것은 분산되어있는 것과 같습니다.

Redis는 세트를 관리하기 위한 몇 가지 명령 을 제공 합니다. 세트 추가, 제거 및 확인과 같은 명백한 사항이 있습니다. 따라서 임의 항목 팝핑 / 읽기와 같은 명확하지 않은 명령과 다른 집합과의 결합 및 교차를 수행하는 명령이 있습니다.

정렬 된 세트 ( 명령 )

정렬 된 세트는 고유 한 값의 모음이기도합니다. 이 이름은 이름에서 알 수 있듯이 주문됩니다. 그것들은 악보 순으로 점수에 따라 정렬됩니다.

이 데이터 유형은 점수 별 빠른 조회에 최적화되어 있습니다. 최고, 최저 또는 그 사이의 값 범위를 얻는 것은 매우 빠릅니다.

높은 점수와 함께 정렬 된 세트에 사용자를 추가하면 완벽한 리더 보드가됩니다. 새로운 최고 점수가 나오면 다시 높은 점수로 세트에 추가하면 리더 보드의 순서가 변경됩니다. 또한 사용자가 마지막으로 방문한 시간과 응용 프로그램에서 활동중인 사람을 추적하는 데에도 좋습니다.

점수가 같은 값을 저장하면 사전 식 (알파벳순)으로 정렬됩니다. 이것은 자동 완성 기능과 같은 것들에 유용 할 수 있습니다.

정렬 된 세트 명령 중 다수는 세트에 대한 명령 과 유사하며 때로는 추가 점수 매개 변수가 있습니다. 점수 관리 및 점수 별 쿼리 명령도 포함되어 있습니다.

지리

Redis에는 지리 데이터를 저장, 검색 및 측정하기위한 몇 가지 명령 이 있습니다. 여기에는 반경 쿼리 및 점 사이의 거리 측정이 포함됩니다.

기술적으로 redis의 지리 데이터는 정렬 된 세트 내에 저장되므로 이는 실제로 별도의 데이터 유형이 아닙니다. 정렬 된 세트의 확장 기능입니다.

비트 맵 및 HyperLogLog

지역과 마찬가지로 이들은 완전히 분리 된 데이터 유형이 아닙니다. 문자열 데이터를 비트 맵 또는 하이퍼 로그인 것처럼 취급 할 수있는 명령입니다.

비트 맵은 내가 참조한 비트 수준 연산자 Strings입니다. 이 데이터 유형은 최근 reddit의 협업 아트 프로젝트 인 r / Place 의 기본 구성 요소였습니다 .

HyperLogLog를 사용하면 매우 작은 공간을 일정하게 사용하여 거의 무제한의 고유 값을 충격적인 정확도로 계산할 수 있습니다. ~ 16KB 만 사용하면 사이트의 순 방문자 수는 수백만 명에 달하더라도 효율적으로 계산할 수 있습니다.

거래와 원 자성

redis의 명령은 원 자성이므로 redis에 값을 쓰 자마자 redis에 연결된 모든 클라이언트가 해당 값을 볼 수 있습니다. 해당 값이 전파 될 때까지 기다리지 않습니다. 기술적으로 memcached도 원 자성이지만, redis가 memcached 이외의 모든 기능을 추가하면 이러한 추가 데이터 유형과 기능 모두 원 자성이라는 점에 주목할 가치가 있습니다.

redis는 관계형 데이터베이스의 트랜잭션과 동일하지 않지만 “낙관적 잠금”( WATCH / MULTI / EXEC ) 을 사용하는 트랜잭션 도 있습니다 .

파이프 라이닝

Redis는 ‘ 파이프 라이닝 ‘ 이라는 기능을 제공합니다 . 실행할 redis 명령이 많은 경우 파이프 라이닝을 사용하여 한 번에 하나씩이 아니라 한 번에 redis로 보낼 수 있습니다.

일반적으로 redis 또는 memcached에 대한 명령을 실행할 때 각 명령은 별도의 요청 / 응답주기입니다. 파이프 라이닝을 사용하면 redis는 여러 명령을 버퍼링하고 한 번에 모두 실행할 수 있으므로 모든 명령에 대한 모든 응답으로 단일 응답으로 응답 할 수 있습니다.

이를 통해 대량 가져 오기 또는 많은 명령이 포함 된 기타 작업에서 더 큰 처리량을 얻을 수 있습니다.

펍 / 서브

Redis는 pub / sub 기능 전용 명령을 가지고 있어 redis가 고속 메시지 브로드 캐스터 역할을 할 수 있습니다. 이를 통해 단일 클라이언트는 채널에 연결된 다른 많은 클라이언트에게 메시지를 게시 할 수 있습니다.

Redis는 거의 모든 도구뿐만 아니라 펍 / 서브도 수행합니다. RabbitMQ 와 같은 전용 메시지 브로커 는 특정 영역에서 이점을 가질 수 있지만 동일한 서버가 영구적 인 내구성있는 대기열과 퍼브 / 서브 워크로드에 필요한 기타 데이터 구조를 제공 할 수 있다는 사실 때문에 Redis는 종종 가장 우수하고 간단한 도구임을 입증 할 것입니다 직업을 위해.

루아 스크립팅

redis의 자체 SQL 또는 저장 프로 시저와 같은 루아 스크립트 를 생각할 수 있습니다 . 그것은 그것보다 더 많거나 적지 만 비유는 대부분 작동합니다.

아마도 redis가 수행하려는 복잡한 계산이있을 수 있습니다. 트랜잭션을 롤백 할 여유가없고 복잡한 프로세스의 모든 단계가 원자 적으로 발생한다는 보장이 필요합니다. 루아 스크립팅으로 이러한 문제와 더 많은 문제를 해결할 수 있습니다.

전체 스크립트는 원자 적으로 실행되므로 논리를 루아 스크립트에 맞추면 낙관적 잠금 트랜잭션이 엉망이되는 것을 피할 수 있습니다.

스케일링

위에서 언급했듯이 redis는 내장 클러스터링 지원을 포함하며라는 자체 고 가용성 도구와 함께 번들로 제공됩니다 redis-sentinel.

결론

망설임없이 새로운 프로젝트 또는 memcached를 아직 사용하지 않는 기존 프로젝트의 경우 memcached보다 redis를 권장합니다.

위의 내용은 내가 memcached를 좋아하지 않는 것처럼 들릴 수 있습니다. 반대로 강력하고 단순하며 안정적이고 성숙하며 강화 된 도구입니다. redis보다 약간 더 빠른 유스 케이스도 있습니다. 나는 memcached를 좋아한다. 나는 그것이 미래의 발전에 많은 의미가 있다고 생각하지 않습니다.

Redis는 memcached가 수행하는 모든 작업을 더 잘 수행합니다. memcached의 성능 이점은 작고 작업 부하에 따라 다릅니다. Redis가 더 빨라질 워크로드와 Redis가 수행 할 수있는 더 많은 워크로드가 있습니다. 기능면에서 거대 걸프 한면에서 작은 성능 차이는 미미한 것으로 보이며 두 도구가 매우 빠르고 효율적이라는 사실은 확장에 대해 염려해야 할 인프라의 마지막 부분 일 수 있습니다.

memcached가 더 적합한 시나리오는 memcached가 이미 캐시로 사용중인 경우입니다. 이미 memcached로 캐싱하는 경우 필요에 따라 계속 사용하십시오. redis로 옮기는 노력은 가치가 없으며 아마도 캐싱을 위해 redis를 사용하려는 경우 시간 가치가 충분하지 않을 수 있습니다. memcached가 요구 사항을 충족하지 못하면 아마도 redis로 이동해야합니다. memcached 이상으로 확장해야하거나 추가 기능이 필요한지 여부에 관계없이 적용됩니다.

---

답변