캐싱을 위해 Redis 서버 와 함께 Ruby 웹앱 을 사용하고 있습니다. 대신 Memcached 를 테스트 할 요점이 있습니까?

더 나은 성능을 제공하는 것은 무엇입니까? Redis와 Memcached의 장단점은 무엇입니까?

고려해야 할 사항 :

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

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

다음과 같은 경우 Redis 사용

1. 캐시에서 항목을 선택적으로 삭제 / 만료해야합니다. (필요합니다)

2. 특정 유형의 키를 쿼리하는 기능이 필요합니다. eq. 'blog1 : posts : *', 'blog2 : categories : xyz : posts : *'입니다. 오 예! 이건 매우 중요합니다. 특정 유형의 캐시 된 항목을 선택적으로 무효화하려면이를 사용하십시오. 또한 이것을 사용하여 프래그먼트 캐시, 페이지 캐시, 주어진 유형의 AR 객체 만 무효화 할 수 있습니다.

3. 지속성 (다시 시작할 때마다 캐시를 ​​예열해야하는 경우가 아니라면 이것도 필요합니다. 거의 변경되지 않는 객체에 매우 중요합니다)

다음과 같은 경우 memcached를 사용하십시오.

1. Memcached는 두통을 유발합니다!
2. 음 ... 클러스터링? meh. 멀리 갈 경우 조각과 AR 객체를 캐싱하기 위해 Varnish와 Redis를 사용하십시오.

내 경험상 Memcached보다 Redis의 안정성이 훨씬 뛰어났습니다.

Memcached는 다중 스레드이며 빠릅니다.

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

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

이 답변은 이미 수락 된 답변에 대한 의견으로 게시하기에는 너무 길어서 별도의 답변으로 작성했습니다.

고려해야 할 사항 중 하나는 캐시 인스턴스에 대한 하드 메모리 상한을 예상 할 수 있는지 여부입니다.

redis는 수많은 기능을 갖춘 nosql 데이터베이스이며 캐싱은 사용할 수있는 옵션 중 하나이므로 필요한만큼 메모리를 할당합니다. 객체를 많이 넣을수록 더 많은 메모리를 사용합니다. 이 maxmemory옵션은 메모리 상한 사용량을 엄격하게 적용하지 않습니다. 캐시 작업시 키가 제거되고 만료됩니다. 키가 모두 같은 크기가 아니기 때문에 내부 메모리 조각화가 발생합니다.

기본적으로 redis는 jemalloc memory allocator를 사용합니다. 이는 메모리 가 작고 빠르기 위해 최선을 다하지만 범용 메모리 할당 기이므로 많은 할당량과 객체 제거가 빠른 속도로 발생하지 않습니다. 이 때문에 일부로드 패턴에서 redis 프로세스는 내부 조각화로 인해 메모리가 누출 될 수 있습니다. 예를 들어, 7Gb RAM이있는 서버가 있고 비 영구적 LRU 캐시로 redis를 사용하려는 경우 maxmemory시간이 지남에 따라 5Gb 로 설정된 redis 프로세스가 점점 더 많은 메모리를 사용하여 결국 총 RAM 한계에 도달 할 수 있습니다. 메모리 부족 킬러가 간섭합니다.

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

그럼에도 불구하고, memcached는 메모리 사용이 강제 및 / 또는 예측 가능한 환경에서 여전히 강력한 위치를 유지하고 있습니다. 10-15k op / s의 작업 부하에서 비 영구적 인 LRU 기반 memcached 대체품으로 최신 안정된 redis (2.8.19)를 사용하려고 시도했으며 메모리가 많이 누출되었습니다. 같은 이유로 워크로드가 같은 이유로 Amazon의 ElastiCache redis 인스턴스를 하루 만에 중단 시켰습니다.

Memcached는 간단한 키 / 값 저장에 능숙하며 key => STRING에 능숙합니다. 이것은 세션 저장에 정말 좋습니다.

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

그것은 당신이 거기에 넣을 것에 달려 있습니다. 내 이해는 성능면에서 꽤 균일하다는 것입니다.

또한 객관적인 벤치 마크를 찾는 것도 행운이 있습니다.

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

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

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

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

레디 스>

1) 클러스터를 통해 캐시 내용을 인덱싱하는 데 사용됩니다. Redis 클러스터에 10 억 개 이상의 키가 분산되어 있으며, Redis 응답 시간이 상당히 짧고 안정적입니다.

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

3) Redis 지속성, 장애 조치 및 백업 (AOF)을 통해 작업이 쉬워집니다.

Memcache>

1) 예. 캐시로 사용할 수있는 최적화 된 메모리입니다. 나는 1MB 미만의 크기로 매우 자주 (초당 50 회 기록) 액세스되는 캐시 내용을 저장하는 데 사용했습니다.

2) 단일 콘텐츠 크기가 1MB보다 크면 memcached에 16GB 중 2GB 만 할당했습니다.

3) 내용이 한계에 가까워짐에 따라 통계에서 응답 시간이 더 빨랐습니다 (redis의 경우가 아님).

전반적인 경험을 요구하는 경우 Redis는 구성하기 쉽고 매우 강력하고 안정적이며 강력한 기능을 제공합니다.

또한이 링크 에서 사용할 수있는 벤치마킹 결과가 있습니다 .

도움이 되었기를 바랍니다!!

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

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

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

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

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

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

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

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

또 다른 보너스는 캐싱 ​​시나리오에서 memcache의 작동 방식을 매우 명확하게 알 수 있지만, redis는 일반적으로 영구 데이터 저장소로 사용되지만 최대에 도달하면 가장 최근에 사용한 항목을 제거하는 것처럼 memcached처럼 작동하도록 구성 할 수 있다는 것입니다 생산 능력.

내가 작업 한 일부 응용 프로그램은 데이터가 어떻게 행동 할 것인지 명확하게하기 위해 두 가지를 모두 사용합니다-memcache의 물건, 존재하지 않는 경우를 처리하는 코드 작성-redis의 물건, 거기에 의존합니다 .

그 이외의 Redis는 일반적으로 기능이 풍부하고 유연하기 때문에 대부분의 사용 사례에서 우수하다고 간주됩니다.

우리가 redis가 (캐시 + 데이터 구조)의 조합이고 memcached가 단지 캐시라고 말하면 잘못이 아닙니다.

redis-2.2.2 및 memcached에 대해 100k 고유 키 및 값을 설정하고 얻는 매우 간단한 테스트입니다. 둘 다 리눅스 VM (CentOS)에서 실행되고 내 클라이언트 코드 (아래 붙여 넣음)는 Windows 바탕 화면에서 실행됩니다.

레디 스

• 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");

여기서 지적하지 않은 한 가지 큰 차이점은 Memcache는 항상 메모리 상한이 있고 Redis는 기본적으로는 아니지만 구성 할 수 있다는 것입니다. 특정 시간 동안 키 / 값을 항상 저장하고 (메모리가 부족하여 절대로 제거하지 않으려는 경우) Redis와 함께 가고 싶습니다. 물론 메모리 부족 문제도 발생할 수 있습니다.

가장 큰 나머지 이유는 전문화입니다.

Redis는 많은 다른 작업을 수행 할 수 있으며 그로 인한 부작용 중 하나는 개발자가 동일한 인스턴스에서 다른 여러 기능 세트를 사용하기 시작할 수 있다는 것입니다. Redis의 LRU 기능을 LRU가 아닌 하드 데이터 스토리지와 함께 캐시에 사용하는 경우 메모리가 부족할 수 있습니다.

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

안정적인 "절대로"LRU 캐시가 필요한 경우 ... Memcached는 설계 상 메모리 부족이 불가능하고 특수 기능으로 인해 개발자가 위험에 처할 수있는 무언가를 만들지 못하므로 청구서에 적합합니다. 우려의 간단한 분리.

Redis에 네트워킹 (TCP 호출)이 포함되어 있어도 성능에 관심이있는 경우 Memcached가 더 빠릅니다. 또한 내부적으로 Memcache가 더 빠릅니다.

Redis는 다른 답변에서 언급했듯이 더 많은 기능을 가지고 있습니다.

우리는 Redis를 직장 프로젝트의 이륙으로 생각했습니다. 우리는 nginx호출 된 모듈 HttpRedis2Module또는 이와 비슷한 것을 사용하면 놀라운 속도를 낼 것이라고 생각했지만 AB 테스트로 테스트 할 때 우리는 틀린 것으로 판명되었습니다.

어쩌면 모듈이 잘못되었거나 레이아웃이 매우 간단했지만 PHP로 데이터를 가져 와서 MongoDB에 넣는 것이 훨씬 빠릅니다. 우리는 APC를 캐싱 시스템으로 사용하고 있으며 php 및 MongoDB와 함께 사용합니다. nginxRedis 모듈 보다 훨씬 빠릅니다 .

내 팁은 직접 테스트하여 환경에 대한 결과를 보여주는 것입니다. 우리는 Redis를 사용하는 것이 의미가 없으므로 프로젝트에서 불필요하다고 결정했습니다.

레디 스가 좋습니다.

찬성은의 Redis이다

1. string, sets, sorted sets, hashes, bitmaps와 같은 많은 데이터 저장 옵션이 있습니다.
2. 레코드의 디스크 지속성
3. 저장 프로 시저 ( LUA스크립트) 지원
4. PUB / SUB를 사용하여 메시지 브로커로 작동 가능

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

1. redis에서와 같이 list, sets와 같은 다양한 데이터 유형 스토리지를 지원하지 않습니다.
2. 주요 단점은 Memcache에 디스크 지속성이 없다는 것입니다.

글쎄, 주로 내 응용 프로그램, 세션을 캐시하기위한 Memcache 및 교리 / orm 쿼리 객체를위한 redis와 함께 사용했습니다. 성능면에서 거의 동일합니다.

다음 은 Amazon에서 제공하는 훌륭한 기사 / 차이점입니다.

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

Memcached의 유일한 장점 은 멀티 스레드이며 빠릅니다. Redis는 많은 훌륭한 기능을 가지고 있으며 매우 빠르지 만 하나의 코어로 제한됩니다.

Memcached에서 지원되지 않는 Redis에 대한 장점

• 스냅 샷-사용자는 언제든지 Redis 캐시의 스냅 샷을 생성하고 보조 스토리지에 유지할 수 있습니다.
• Set, Map, SortedSet, List, BitMaps 등과 같은 많은 데이터 구조를 지원합니다.
• Redis에서 Lua 스크립팅 지원