Memcached 대 Redis? [닫은]

질문자 :Sagiv Ofek

폐쇄 . 이 질문은 의견 기반 입니다. 현재 답변을 받고 있지 않습니다.

작년에 문을 닫았습니다.

잠김 . 이 질문과 해당 답변은 주제와 관련이 없지만 역사적 의미가 있기 때문에 잠겨 있습니다. 현재 새로운 답변이나 상호 작용을 허용하지 않습니다.

캐싱을 위해 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 를 시도할 수 있으며 문서의 각 명령에 대한 실시간 대화식 예제도 제공합니다.

이제 memcached보다 redis에 대한 스택 오버플로 결과가 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도 원자적이지만 memcached 외에 이 모든 기능을 추가하는 redis에서는 이러한 모든 추가 데이터 유형과 기능도 원자적이라는 점에 주목할 가치가 있으며 다소 인상적입니다.

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

파이프라이닝

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

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

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

게시/구독

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

Redis는 거의 모든 도구와 마찬가지로 게시/구독을 수행합니다. RabbitMQ 와 같은 전용 메시지 브로커는 특정 영역에서 이점이 있을 수 있지만 동일한 서버가 pub/sub 워크로드에 필요할 수 있는 영구 지속 대기열 및 기타 데이터 구조를 제공할 수도 있다는 사실을 감안할 때 Redis는 종종 가장 좋고 가장 간단한 도구임이 증명될 것입니다. 일을 위해.

루아 스크립팅

redis의 자체 SQL이나 저장 프로시저와 같은 lua 스크립트 를 생각할 수 있습니다. 그 이상도 이하도 있지만 유추는 대부분 효과가 있습니다.

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

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

스케일링

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

결론

주저 없이 새로운 프로젝트나 이미 memcached를 사용하지 않는 기존 프로젝트에 대해 memcached보다 redis를 권장합니다.

위의 내용은 내가 memcached를 좋아하지 않는 것처럼 들릴 수 있습니다. 반대로 강력하고 단순하며 안정적이며 성숙하고 강화된 도구입니다. redis보다 조금 더 빠른 사용 사례도 있습니다. 나는 memcached를 사랑한다. 나는 그것이 미래의 발전을 위해 큰 의미가 없다고 생각합니다.

Redis는 memcached가 하는 모든 일을 종종 더 잘 수행합니다. memcached의 성능 이점은 미미하고 작업 부하에 따라 다릅니다. 또한 redis가 더 빨라질 워크로드와 memcached가 할 수 없는 일을 redis가 수행할 수 있는 더 많은 워크로드가 있습니다. 기능의 거대한 격차와 두 도구가 모두 매우 빠르고 효율적이라는 사실에 직면하여 작은 성능 차이는 사소한 것처럼 보입니다. 확장에 대해 걱정해야 하는 인프라의 마지막 부분이 될 수도 있습니다.

memcached가 더 적합한 시나리오는 단 하나입니다. memcached가 이미 캐시로 사용 중인 경우입니다. 이미 memcached를 사용하여 캐싱하고 있다면 필요에 따라 계속 사용하십시오. redis로 이동하려는 노력의 가치가 없을 가능성이 높으며, 캐싱용으로만 redis를 사용하려는 경우 시간을 투자할 가치가 있는 충분한 이점을 제공하지 못할 수 있습니다. memcached가 요구 사항을 충족하지 못하면 redis로 이동해야 합니다. memcached 이상으로 확장해야 하거나 추가 기능이 필요한 경우에 마찬가지입니다.

Carl Zulauf

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

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

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

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

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

1. Memcached는 당신에게 두통을 줍니다!
2. 음... 클러스터링? 음. 멀리 갈 경우 조각 및 AR 개체 캐싱에 Varnish 및 Redis를 사용하십시오.

내 경험상 Memcached보다 Redis가 훨씬 더 안정적이었습니다.

SMathew

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

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

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

W. Andrew Loe III

이미 수락된 답변에 댓글로 올리기에는 너무 길어서 별도 답변으로 올립니다

또한 고려해야 할 한 가지는 캐시 인스턴스에 하드 상한 메모리 제한이 있을 것으로 예상하는지 여부입니다.

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

기본적으로 redis는 jemalloc 메모리 할당자를 사용합니다. 이 할당자는 메모리가 작고 빠르기 위해 최선을 다하지만 범용 메모리 할당자이며 많은 할당과 빠른 속도로 발생하는 개체 제거를 따라갈 수 없습니다. 이 때문에 일부 로드 패턴에서 redis 프로세스는 내부 단편화로 인해 분명히 메모리 누수가 발생할 수 있습니다. 예를 들어, 7Gb RAM이 있는 서버가 있고 redis를 비영구 LRU 캐시로 사용하려는 경우 maxmemory 설정된 redis 프로세스가 점점 더 많은 메모리를 사용하여 결국 총 RAM 제한에 도달할 수 있습니다. 메모리 부족 킬러가 방해할 때까지.

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

그렇긴 해도 memcached는 메모리 사용량이 적용되거나 예측 가능해야 하는 환경에서 여전히 강력한 위치를 차지하고 있습니다. 10-15k op/s의 워크로드에서 드롭인 비영구 LRU 기반 memcached 교체로 최신 안정적인 redis(2.8.19)를 사용하려고 시도했으며 메모리가 많이 누출되었습니다. 같은 작업 부하가 같은 이유로 하루 정도에 Amazon의 ElastiCache redis 인스턴스를 충돌시켰습니다.

artyom

Memcached는 간단한 키/값 저장소가 되고 key => STRING을 잘 합니다. 이것은 세션 저장에 정말 좋습니다.

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

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

또한 객관적인 벤치마크를 찾으면 행운을 빕니다.

Erik Petersen

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

그리고 약간의 혼동 없이는 완전한 벤치마크 링크가 없으므로 Dormondo의 LiveJournal 및 Antirez Weblog 에서 충돌하는 벤치마크도 확인하십시오.

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

Paul Smith

내가 작업한 캐싱 프록시에서 memcached와 redis를 함께 사용할 수 있는 기회가 생겼습니다. 정확히 내가 사용한 것과 같은 이유를 공유하겠습니다....

레디스 >

1) 클러스터에서 캐시 콘텐츠를 인덱싱하는 데 사용됩니다. 나는 redis 클러스터에 걸쳐 10억 개 이상의 키를 가지고 있으며 redis 응답 시간은 상당히 짧고 안정적입니다.

2) 기본적으로 키/값 저장소이므로 응용 프로그램에서 비슷한 것이 있는 곳이면 어디든 번거롭게 redis를 사용할 수 있습니다.

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

멤캐시 >

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

2) 단일 콘텐츠 크기가 >1MB인 경우에도 memcached용으로 16GB 중 2GB만 할당했습니다.

3) 콘텐츠가 한계에 가까워짐에 따라 때때로 통계에서 더 높은 응답 시간을 관찰했습니다(redis의 경우가 아님).

전반적인 경험을 묻는다면 Redis는 구성하기 쉽고 안정적이고 강력한 기능으로 훨씬 유연하기 때문에 훨씬 친환경적입니다.

또한, 이 링크 에서 사용할 수 있는 벤치마킹 결과가 있습니다. 아래에는 동일한 결과가 거의 없습니다.

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

Jain Rach

시험. 몇 가지 간단한 벤치마크를 실행합니다. 나는 대부분 memcached를 사용하고 Redis를 새로운 아이로 생각했기 때문에 오랫동안 스스로를 구식 코뿔소라고 생각했습니다.

현재 회사에서는 Redis를 기본 캐시로 사용했습니다. 성능 통계를 조사하고 간단히 테스트를 시작했을 때 Redis는 성능 면에서 MySQL 과 비슷하거나 최소한으로 느렸습니다.

Memcached는 단순하지만 Redis를 완전히 없애버렸습니다. 훨씬 더 잘 확장되었습니다.

• 더 큰 값의 경우(슬래브 크기 변경이 필요하지만 작동함)
• 여러 동시 요청에 대해

또한 memcached 축출 정책이 훨씬 더 잘 구현되어 캐시가 처리할 수 있는 것보다 많은 데이터를 처리하면서 전반적으로 더 안정적인 평균 응답 시간을 얻을 수 있다고 생각합니다.

일부 벤치마킹 결과 Redis의 경우 성능이 매우 저조한 것으로 나타났습니다. 이것은 많은 변수와 관련이 있다고 생각합니다.

• Redis를 실행하는 하드웨어 유형
• 저장하는 데이터 유형
• 가져오기 및 세트의 양
• 앱이 얼마나 동시성인지
• 데이터 구조 스토리지가 필요합니까?

개인적으로 저는 Redis 작성자가 동시성과 멀티스레딩에 대해 가지고 있는 관점을 공유하지 않습니다.

mdomans

또 다른 보너스는 memcache가 캐싱 시나리오에서 어떻게 작동할지 매우 명확할 수 있다는 것입니다. 반면 redis는 일반적으로 영구 데이터 저장소로 사용되지만 최대에 도달하면 memcached(즉, 최소 최근 사용 항목 제거)처럼 작동하도록 구성할 수 있습니다. 용량.

내가 작업한 일부 앱은 데이터가 어떻게 작동하도록 의도했는지 명확하게 하기 위해 둘 다 사용합니다. memcache의 경우 데이터가 없는 경우를 처리하기 위해 코드를 작성합니다. redis의 경우 데이터가 있는 것에 의존합니다. .

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

Scott Schulthess

redis는 (cache + data structure) 조합이고 memcached는 그냥 캐시라고 해도 틀리지 않을 것입니다.

Atif Hussain

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

레디스

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

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

멤캐시드

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

Prabhu Nandan Kumar

여기에서 지적되지 않은 한 가지 주요 차이점은 Memcache에는 항상 상한 메모리 제한이 있는 반면 Redis에는 기본적으로는 없지만 구성할 수 있다는 것입니다. 항상 특정 시간 동안 키/값을 저장하고 싶다면(메모리 부족으로 인해 절대 제거하지 않음) Redis를 사용하는 것이 좋습니다. 물론, 당신은 또한 메모리 부족 문제의 위험이 있습니다 ...

Ztyx

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

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

Denys

남은 가장 큰 이유는 전문성이다.

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

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

신뢰할 수 있는 "절대 다운되지 않는" LRU 캐시가 필요한 경우... Memcached는 설계상 메모리 부족이 불가능하고 전문화 기능으로 인해 개발자가 이를 위험에 빠뜨릴 수 있는 것으로 만들지 못하도록 방지할 수 있습니다. 간단한 관심사 분리.

brightball

우리는 Redis를 직장에서 우리 프로젝트의 부하로 생각했습니다. nginx HttpRedis2Module 또는 이와 유사한 모듈을 사용하면 놀라운 속도를 얻을 수 있다고 생각했지만 AB-test로 테스트할 때 잘못된 것으로 판명되었습니다.

모듈이 나빴거나 레이아웃이 잘못되었을 수도 있지만 매우 간단한 작업이었고 php로 데이터를 가져와 MongoDB에 넣는 것이 훨씬 더 빨랐습니다. 우리는 APC를 캐싱 시스템으로 사용하고 있으며 해당 PHP 및 MongoDB와 함께 사용하고 있습니다. nginx Redis 모듈보다 훨씬 빠릅니다.

내 팁은 직접 테스트하는 것입니다. 그렇게 하면 환경에 대한 결과가 표시됩니다. Redis를 사용하는 것은 의미가 없기 때문에 프로젝트에서 불필요하다고 결정했습니다.

Ms01

레디스가 낫습니다.

Redis 의 장점은 ,

1. 문자열, 집합, 정렬된 집합, 해시, 비트맵과 같은 많은 데이터 저장 옵션이 있습니다.
2. 레코드의 디스크 지속성
3. 저장 프로시저( LUA 스크립팅) 지원
4. PUB/SUB를 사용하여 메시지 브로커 역할을 할 수 있습니다.

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

1. list 와 같은 다양한 데이터 유형 저장소를 지원하지 않으며 redis에서와 같이 설정합니다.
2. 주요 단점은 Memcache에 디스크 지속성이 없다는 것입니다.

athavan kanapuli

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

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

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

Memcached에서 지원하지 않는 Redis의 장점

• 스냅샷 - 사용자는 Redis 캐시의 스냅샷을 찍고 임의의 시점에서 보조 스토리지에 유지할 수 있습니다.
• Set, Map, SortedSet, List, BitMaps 등과 같은 많은 데이터 구조에 대한 내장 지원
• redis에서 Lua 스크립팅 지원

nagendra547

출처 : http:www.stackoverflow.com/questions/10558465/memcached-vs-redis