it-gundan.com

Memcached 대 Redis?

우리는 캐싱을 위해 Redis server가있는 Ruby 웹 응용 프로그램을 사용하고 있습니다. Memcached 대신 테스트 할 지점이 있습니까?

무엇이 우리에게 더 나은 성과를 줄 것입니까? Redis와 Memcached간에 장단점이 있습니까?

고려해야 할 점 :

  • 읽기/쓰기 속도.
  • 메모리 사용.
  • 디스크 I/O 덤프.
  • 스케일링.
1317
Sagiv Ofek

요약 (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에는 타사 도구없이 디스크에 덤프하는 메커니즘이 없습니다.
  • Scaling : 둘 이상의 인스턴스가 캐시로 필요하기 전에 두 개의 헤드 룸을 제공합니다. 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를 쉽게 설정할 수 있습니다. real 데이터베이스입니다.

많은 데이터 유형

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

문자열 ( 명령 )

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

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

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

해시 ( 명령 )

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

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

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

리스트 ( 명령 )

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

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

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

세트 ( 명령 )

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

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

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

정렬 된 세트 ( 명령 )

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

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

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

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

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

지리

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

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

비트 맵 및 HyperLogLog

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

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

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

거래와 원 자성

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

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

파이프 라이닝

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

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

이를 통해 대량 가져 오기 또는 많은 명령이 포함 된 기타 작업에 대한 처리량을 크게 높일 수 있습니다.

펍/서브

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

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

루아 스크립팅

lua scripts 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 이상으로 확장해야하거나 추가 기능이 필요한지 여부에 관계없이 적용됩니다.

1955
Carl Zulauf

다음과 같은 경우 Redis 사용

  1. 캐시에서 항목을 선택적으로 삭제하거나 만료해야합니다. (당신이 필요해)

  2. 특정 유형의 키를 쿼리 할 수 ​​있어야합니다. eq. 'blog1 : posts : *', 'blog2 : categories : xyz : posts : *'등이 있습니다. 오 예! 이건 매우 중요합니다. 특정 유형의 캐시 된 항목을 선택적으로 무효화하려면이 옵션을 사용하십시오. 이 옵션을 사용하여 조각 캐시, 페이지 캐시, 지정된 유형의 AR 개체 만 무효화 할 수도 있습니다.

  3. 지속성 (다시 시작할 때마다 캐시를 ​​워밍업해야하는 경우가 아니면 괜찮을 것입니다.) 거의 변경되지 않는 개체의 경우 매우 중요합니다.

Memcached if를 사용하십시오.

  1. Memcached 당신을 헤치고 준다!
  2. 음 ... 클러스터링? 나. 그렇게 할 수 있다면 바니쉬 (Varnish)와 레디 스 (Redis)를 사용하여 프래그먼트와 AR 객체를 캐싱하십시오.

내 경험에 비추어 볼 때 Redcis는 Memcached보다 안정성이 훨씬 뛰어났습니다.

132
SMathew

Memcached는 멀티 스레드 및 고속입니다.

Redis는 많은 기능을 가지고 있으며 매우 빠르지 만 이벤트 루프를 기반으로하므로 하나의 코어로 완전히 제한됩니다.

우리는 둘 다 사용합니다. Memcached는 객체 캐싱에 사용되며 주로 데이터베이스의 읽기로드를 줄입니다. Redis는 시계열 데이터를 롤업하는 데 편리한 정렬 된 세트와 같은 것에 사용됩니다.

89

이것은 너무 오래되어서 이미 받아 들여진 답에 주석으로 게시 할 수 없으므로 나는 별도의 답으로

한 가지 고려해야 할 점은 캐시 인스턴스에 대해 하드 상위 메모리 제한이 있는지 여부입니다.

Redis는 기능이 많은 nosql 데이터베이스이므로 캐싱은 사용할 수있는 유일한 옵션이며 필요에 따라 메모리를 할당합니다. 개체를 많이 넣을수록 더 많은 메모리가 사용됩니다. maxmemory 옵션은 상위 메모리 제한 사용을 엄격하게 적용하지 않습니다. 캐시로 작업하면 키가 제거되고 만료됩니다. 기회가 귀하의 키가 모두 같은 크기가 아니므로 내부 메모리 단편화가 발생합니다.

기본적으로 redis는 jemalloc memory allocator를 사용합니다. 메모리 할당기는 메모리가 가장 작고 빠름을 모두 시도하지만 범용 메모리 할당 자이며 a 높은 비율. 이 때문에 일부로드 패턴에서는 내부 조각화로 인해 redis 프로세스에서 메모리 누수가 발생할 수 있습니다. 예를 들어 7Gb RAM의 서버가 있고 비 영구적 LRU 캐시로 redis를 사용하려는 경우 시간이 지남에 따라 maxmemory이 5Gb로 설정된 redis 프로세스가 점점 더 많은 메모리를 사용하게됩니다 결국 메모리 부족 킬러가 방해 할 때까지 총 RAM한계에 도달합니다.

memcached는 완전히 다른 방식으로 메모리를 관리하므로 위에 설명 된 시나리오에 더 적합합니다. memcached는 하나의 큰 메모리 덩어리 (모든 것이 필요할 것입니다)를 할당 한 다음 자체적으로 구현 된 슬래브 할당 자 를 사용하여이 메모리를 관리합니다. 더욱이 memcached는 LRU 축출이 객체 크기를 고려하여 수행 될 때 실제로 슬래 이브 단위의 LRU 알고리즘을 사용함 때문에 내부 조각화를 낮게 유지하려고합니다.

Memcached는 여전히 메모리 사용을 강화하거나 예측할 수 있어야하는 환경에서 여전히 강력한 위치를 차지하고 있습니다. 우리는 최신 안정적인 redis (2.8.19)를 drop-in non-persistent LRU 기반 memcached 대체물로 10-15k op/s의 작업량으로 사용하려고 시도했으며 메모리 A를 많이 유출했습니다. 동일한 작업로드로 인해 동일한 이유로 Amazon의 ElastiCache redis 인스턴스가 하루 정도 지나면 충돌이 발생했습니다.

86
artyom

Memcached는 간단한 키/값 저장소가되는 데 능숙하며 키 => STRING을 사용하는 것이 좋습니다. 이것은 세션 저장에 정말 좋습니다.

Redis는 key => SOME_OBJECT를 잘 수행합니다.

그것은 당신이 거기에 끼워 넣으려는 것에 정말로 달려 있습니다. 내 이해는 성능 측면에서 그들은 꽤 균등합니다.

또한 객관적 벤치 마크를 찾는 행운을 빌어서 친절하게도 내 길을 보내주십시오.

45
Erik Petersen

Crsto 작성 스타일이 마음에 들지 않으면 Systoilet 블로그의 Redis vs Memcached 는 유용성 관점에서 읽을 가치가 있지만 결론을 내리기 전에 주석의 앞뒤를 읽으십시오. 성능에; 몇 가지 방법 론적 문제 (단일 스레드 바쁜 루프 테스트)가 있으며 Redis는 기사가 작성된 이후로 약간 개선되었습니다.

약간의 혼란도없이 벤치 마크 링크가 완성되지 않았으므로 Dormondo 's LiveJournalAntirez Weblog 에서 충돌하는 벤치 마크도 확인하십시오.

Edit -Antirez가 지적했듯이 Systoilet 분석은 다소 잘못된 것입니다. 단일 스레딩 부족을 뛰어 넘어도 벤치 마크의 성능 차이가 서버 처리량이 아닌 클라이언트 라이브러리에 기인 할 수 있습니다. Antirez Weblog 의 벤치 마크는 실제로 동일한 입을 가진 훨씬 더 많은 사과 대 사과를 비교합니다.

37
Paul Smith

내가 일한 캐싱 프록시에서 memcached와 redis를 함께 사용할 수있는 기회를 얻었으므로, 내가 정확히 무엇을 사용하고 동일한 이유를 사용했는지 공유하도록하겠습니다 ....

Redis>

1) 클러스터를 통해 캐시 내용을 색인화하는 데 사용됩니다. 나는 10 억 개 이상의 키가 redis 클러스터를 통해 퍼져 나갔고, redis 응답 시간은 상당히 적고 안정적입니다.

2) 기본적으로 키/값 저장소이므로 응용 프로그램에서 비슷한 점이있는 곳이라면 redis를 많이 사용할 수 있습니다.

3) Redis persistency, failover 및 backup (AOF)은 작업을보다 쉽게 ​​만듭니다.

Memcache>

1) 예, 캐시로 사용할 수있는 최적화 된 메모리입니다. 나는 캐시 컨텐트를 매우 자주 (50 초당 히트로) 액세스 할 수 있도록 저장하는데 사용했다. 크기는 1 MB 미만이었다.

2) 내 단일 콘텐츠 크기가 1MB를 넘을 때도 memcached 용으로 16GB 중 2GB 만 할당했습니다.

3) 내용이 한계 근처에서 증가함에 따라 때때로 통계에서 응답 시간이 더 빨랐습니다 (재발로 인한 경우는 아님).

전체 경험을 요청하면 Redis는 구성이 쉽고 안정적이며 견고한 기능으로 훨씬 유연합니다.

또한, link 에서 사용할 수있는 벤치마킹 결과가 있습니다. 아래에는 동일한 하이라이트가 있지만,

enter image description here

enter image description here

희망이 도움이 !!

22
Jain Rach

또 다른 보너스는 캐싱 ​​시나리오에서 memcache가 어떻게 작동하는지 명확하게 알 수 있습니다. 반면 redis는 일반적으로 영구 데이터 저장소로 사용되지만 memcached라고도 일컬어 지도록 구성 할 수 있지만 최근에 사용한 최소 항목은 최대 값에이를 때 발생합니다 생산 능력.

필자가 작업 한 일부 응용 프로그램은 데이터를 어떻게 조작 할 것인가를 분명히하기 위해 사용됩니다. memcache에 들어있는 경우, 그렇지 않은 경우를 처리하는 코드를 작성합니다. .

Redis는 일반적으로 대부분의 유스 케이스가 기능이 풍부하고 유연성이 뛰어나므로 우수한 것으로 간주됩니다.

13
Scott Schulthess

테스트. 간단한 벤치 마크를 실행하십시오. 오랫동안 memcached를 사용하고 Redis를 새로운 아이로 생각한 이래로 나는 오래 된 학교 코뿔소라고 생각했습니다.

현재 회사와 함께 Redis가 기본 캐시로 사용되었습니다. 성능 통계를 파고 테스트를 시작했을 때 Redis는 성능 측면에서 MySQL보다 비슷하거나 최소한 느리게였습니다.

Memcached는 단순하지만 Redis를 물 밖으로 불어 넣었습니다. totally. 훨씬 더 잘 확장되었습니다.

  • 더 큰 값 (슬래브 크기의 변경이 필요하지만 효과가 있음)
  • 여러 개의 동시 요청

또한 memcached 제거 정책은 제 생각에 훨씬 더 잘 구현되어 캐시가 처리 할 수있는 것보다 더 많은 데이터를 처리하는 동안 전체적으로 평균 응답 시간이 더 안정적입니다.

일부 벤치마킹에 따르면 Redis는 우리의 경우 성능이 매우 좋지 않습니다. 이것은 많은 변수와 관련이 있다고 생각합니다.

  • redis를 실행하는 하드웨어 유형
  • 저장하는 데이터 유형
  • 가져 오기 및 설정 금액
  • 앱의 동시성
  • 데이터 구조 스토리지가 필요하십니까

개인적으로 Redis 작성자가 동시성과 멀티 스레딩에 대한 견해를 공유하지 않습니다.

13
mdomans

우리가 redis가 (캐시 + 데이터 구조)의 조합 인 반면 memcached는 캐시 일 뿐이라는 것은 잘못이 아닙니다.

9
Atif Hussain

주요 차이점 중 하나는 Memcache가 항상 상위 메모리 제한을 가지고있는 반면 Redis는 기본적으로 (그러나 구성 할 수 있음) 기억하지 못한다는 것입니다. 특정 시간 동안 키/값을 저장하고 싶을 때 (그리고 메모리가 부족하기 때문에 절대로 키를 제거하지 않으려는 경우) Redis와 함께 가고 싶습니다. 물론 메모리가 부족하다는 문제가 발생할 수도 있습니다 ...

7
Ztyx

매우 간단한 테스트로 redis-2.2.2와 memcached에 대해 100k 고유 키와 값을 설정하고 가져옵니다. 둘 다 리눅스 VM (CentOS)에서 실행 중이며 내 클라이언트 코드 (아래 붙여 넣기)는 Windows 데스크톱에서 실행됩니다.

Redis

  • 100000 값을 저장하는 데 걸리는 시간은 = 18954ms입니다.

  • 100000 값을로드하는 데 걸리는 시간은 = 18328ms입니다.

Memcached

  • 100000 값을 저장하는 데 걸리는 시간은 = 797ms입니다.

  • 100000 값을 검색하는 데 걸리는 시간은 = 38984ms입니다.


Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");
7

우리는 Redis를 직장에서의 프로젝트에 대한로드 오프 이륙으로 생각했습니다. 우리는 nginx에서 HttpRedis2Module 또는 이와 유사한 모듈을 사용하여 속도를 향상시킬 수 있다고 생각했지만 AB 테스트로 테스트 할 때 우리는 틀린 것으로 입증되었습니다.

어쩌면 모듈이 잘못되었거나 레이아웃이 잘못되었지만 매우 간단한 작업이었으며 PHP로 데이터를 가져 와서 MongoDB에 저장하는 것이 더 빠릅니다. 우리는 APC를 캐싱 시스템으로 사용하고 있으며 PHP와 MongoDB를 사용하고 있습니다. 훨씬 더 빨리 다음 nginx Redis 모듈이었다.

내 팁은 직접 테스트하여 환경에 대한 결과를 보여줍니다. 우리는 Redis 사용이 프로젝트에서 불필요하다는 결론을 내 렸습니다.

5
Ms01

가장 큰 이유는 전문화 때문입니다.

Redis는 많은 다른 작업을 수행 할 수 있으며 개발자가 동일한 인스턴스에서 많은 다른 기능 세트를 사용할 수 있다는 부작용이 있습니다. LRU가 아닌 측면 하드 데이터 저장소의 캐시에 Redis의 LRU 기능을 사용하는 경우 메모리가 완전히 소모 될 수 있습니다.

특정 시나리오를 피하기 위해 전용 Redis 인스턴스를 LRU 인스턴스로만 설정하려는 경우 Memcached를 통해 Redis를 사용하는 강력한 이유는 없습니다.

안정적인 "절대로 쓰지 말라"LRU 캐시가 필요한 경우 Memcached는 설계 상 메모리가 부족하여 전문 기능을 사용할 수 없기 때문에이 법안에 부합 할 것입니다. 개발자는이를 통해 개발자가 위험을 무릅 쓰지 않도록 할 수 없습니다. 관심사의 간단한 분리.

5
brightball

Redis는 네트워킹 (TCP 호출)을 포함하기 때문에 Memcached는 성능에 관심이 있다면 더 빠릅니다. 또한 내부적으로 Memcache가 더 빠릅니다.

Redis는 다른 답변에서 언급 한 것처럼 더 많은 기능을 제공합니다.

3
Denys

Redis는 더 좋습니다. Redis의 장점은,

1.It has a lot of data storage options such  as  string  , sets , sorted sets ,  hashes ,  bitmaps
2.Disk Persistence of records 
3.Stored Procedure (LUA acripting)  support
4.Can act as a Message Broker using PUB/SUB

반면 Memcache는 메모리 키 값 캐시 유형의 시스템입니다.

  1. 목록과 같은 다양한 데이터 유형 저장소에 대한 지원이 없습니다.
  2. Memcache는 디스크 지속성이 없습니다.
2
athavan kanapuli

Here 아마존에서 제공하는 정말 훌륭한 기사/차이점입니다

Redis는 memcached와 비교하여 확실한 승자입니다.

Memcached에 대한 단 하나의 플러스 포인트 그것은 다중 스레드이며 빠릅니다. Redis는 많은 훌륭한 기능을 가지고 있으며 매우 빠르지 만 하나의 코어로 제한됩니다.

0
nagendra547

글쎄, 대부분 내 애플 리케이션, Memcache 캐시에 대한 세션 및 교리/오만 쿼리 개체 redis 함께 사용됩니다. 성능면에서 거의 동일합니다.

0
Muhammad Taqi