다음 콘텐츠는 동료의 요약에서 공유하기 위해 게시된 내용입니다. Memcached Memcached의 장점:
Memcached는 멀티 코어를 활용할 수 있으며 단일 인스턴스의 처리량은 수십만 QPS에 도달할 정도로 매우 높습니다(키와 값의 바이트 크기 및 서버 하드웨어의 성능에 따라 일상 환경의 최대 QPS). 약 4-6w입니다). 최대 수용 능력에 적합합니다.
세션 핸들로 직접 구성을 지원합니다.
함정이 거의 없습니다. Memcached의 한계:
풍부한 데이터 유형을 지원할 수 있는 Redis와 달리 단순한 키/값 데이터 구조만 지원합니다.
지속할 수 없고, 데이터를 백업할 수 없으며, 캐싱에만 사용할 수 있으며, 다시 시작하면 모든 데이터가 손실됩니다.
데이터 동기화를 수행할 수 없으며 MC의 데이터를 다른 MC 인스턴스로 마이그레이션할 수 없습니다.
Memcached 메모리 할당은 Slab Allocation 메커니즘을 사용하여 메모리를 관리합니다. 값 크기 분포의 차이가 크면 메모리 활용도가 낮아지고, 활용도가 낮은 경우에도 킥아웃되는 등의 문제가 발생합니다. 사용자는 가치 디자인에 주의를 기울여야 합니다.
Redis Redis의 장점:
string(문자열), list(이중 연결 목록), dict(해시 테이블), set(집합), zset(정렬된 집합), hyperloglog(카디널리티 추정) 등 다양한 데이터 구조 지원
지속성 작업을 지원하고 데이터 백업 또는 데이터 복구 작업을 위해 AOF 및 RDB 데이터를 디스크에 유지할 수 있습니다. 이는 데이터 손실을 방지하는 더 나은 방법입니다.
복제를 통한 데이터 복제를 지원합니다. 마스터-슬레이브 메커니즘을 통해 데이터의 실시간 동기 복제가 수행될 수 있습니다. 마스터-슬레이브 메커니즘은 Redis가 HA를 수행하는 중요한 수단입니다.
단일 스레드 요청, 모든 명령이 순차적으로 실행되며 동시 상황에서 데이터 일관성 문제를 고려할 필요가 없습니다.
메시지 구독 및 알림에 사용할 수 있는 게시/구독 메시지 구독 메커니즘을 지원합니다.
간단한 거래 요구 사항을 지원하지만 업계에서 사용 사례가 거의 없고 성숙하지도 않습니다.
Redis의 한계:
Redis는 단일 스레드만 사용할 수 있으며 성능은 CPU 성능에 의해 제한됩니다. 따라서 단일 인스턴스 CPU는 데이터 구조, 데이터 크기 및 서버 하드웨어 성능에 따라 초당 최대 5-6w QPS에 도달할 수 있습니다. 일상 환경의 QPS는 약 1-2w입니다.
간단한 거래 요구 사항을 지원하지만 업계에서 사용 시나리오가 거의 없고 미성숙하여 장점과 단점이 모두 있습니다.
Redis는 문자열 유형에서 더 많은 메모리를 소비합니다. dict(해시 테이블)를 사용하여 스토리지를 압축하여 메모리 소비를 줄일 수 있습니다.
:) 다음은 제가 개인적으로 추가한 내용입니다
Mc와 Redis는 모두 키-값 유형이므로 서로 다른 데이터 세트 간의 관계를 설정하는 데 적합하지 않으며 쿼리 검색에도 적합하지 않습니다. 예를 들어, redis 키 pattern의 일치 작업은 redis 성능에 재앙입니다.
모고디비
mogodb는 문서 데이터베이스입니다. 먼저 xml, json, bson 형태의 데이터를 저장할 수 있는 문서 데이터베이스에 대해 설명하겠습니다. 이러한 데이터는 자체 설명적이며 계층적 트리와 같은 데이터 구조를 나타냅니다. Redis는 해시를 사용하여 간단한 관계형 데이터를 저장할 수 있습니다.
mogodb는 json 형식의 데이터를 저장합니다.
적합한 시나리오: 이벤트 녹화, 콘텐츠 관리 또는 댓글 시스템과 같은 블로그 플랫폼.
Nosq에는 현재 많은 제품이 있으며, 건축가의 선택은 주로 다음 두 가지 요소에 의해 결정됩니다.
1) 애플리케이션 사용 시나리오에 적합합니다. 예를 들어 mogodb를 사용하는 데 더 적합하며 mc도 구현할 수 있습니다. (애플리케이션에서 데이터를 json으로 변환하여 저장하지만 일부 데이터를 업데이트하는 것이 불편합니다.)
2) 팀은 자신에게 익숙한 기술을 개발합니다. 예를 들어 팀에서 mc를 사용해 왔기 때문에 redis 대신 mc를 선택하는 것이 제한됩니다.
개발팀이 mogodb를 사용해 왔으며 kv nosq에 적합한 시나리오에서 mogodb를 계속 선택하는 중간에서 심각한 상황도 있습니다.
Redis와 Memcache는 두 가지 캐싱 메커니즘으로 주로 데이터베이스 부담을 줄이고 액세스 속도를 향상시키는 데 사용됩니다. Redis는 캐시를 하드 디스크에 저장하고 컴퓨터를 다시 시작하여 계속 호출할 수 있습니다. Memcache에는 단일 기능과 높은 효율성으로 단순히 메모리에 캐시되는 기능도 많이 있습니다. mongoDB의 경우 이것은 단지 데이터베이스일 뿐입니다
다음 콘텐츠는 동료의 요약에서 공유하기 위해 게시된 내용입니다.
Memcached
Memcached의 장점:
Memcached는 멀티 코어를 활용할 수 있으며 단일 인스턴스의 처리량은 수십만 QPS에 도달할 정도로 매우 높습니다(키와 값의 바이트 크기 및 서버 하드웨어의 성능에 따라 일상 환경의 최대 QPS). 약 4-6w입니다). 최대 수용 능력에 적합합니다.
세션 핸들로 직접 구성을 지원합니다.
함정이 거의 없습니다.
Memcached의 한계:
풍부한 데이터 유형을 지원할 수 있는 Redis와 달리 단순한 키/값 데이터 구조만 지원합니다.
지속할 수 없고, 데이터를 백업할 수 없으며, 캐싱에만 사용할 수 있으며, 다시 시작하면 모든 데이터가 손실됩니다.
데이터 동기화를 수행할 수 없으며 MC의 데이터를 다른 MC 인스턴스로 마이그레이션할 수 없습니다.
Memcached 메모리 할당은 Slab Allocation 메커니즘을 사용하여 메모리를 관리합니다. 값 크기 분포의 차이가 크면 메모리 활용도가 낮아지고, 활용도가 낮은 경우에도 킥아웃되는 등의 문제가 발생합니다. 사용자는 가치 디자인에 주의를 기울여야 합니다.
Redis
Redis의 장점:
string(문자열), list(이중 연결 목록), dict(해시 테이블), set(집합), zset(정렬된 집합), hyperloglog(카디널리티 추정) 등 다양한 데이터 구조 지원
지속성 작업을 지원하고 데이터 백업 또는 데이터 복구 작업을 위해 AOF 및 RDB 데이터를 디스크에 유지할 수 있습니다. 이는 데이터 손실을 방지하는 더 나은 방법입니다.
복제를 통한 데이터 복제를 지원합니다. 마스터-슬레이브 메커니즘을 통해 데이터의 실시간 동기 복제가 수행될 수 있습니다. 마스터-슬레이브 메커니즘은 Redis가 HA를 수행하는 중요한 수단입니다.
단일 스레드 요청, 모든 명령이 순차적으로 실행되며 동시 상황에서 데이터 일관성 문제를 고려할 필요가 없습니다.
메시지 구독 및 알림에 사용할 수 있는 게시/구독 메시지 구독 메커니즘을 지원합니다.
간단한 거래 요구 사항을 지원하지만 업계에서 사용 사례가 거의 없고 성숙하지도 않습니다.
Redis의 한계:
Redis는 단일 스레드만 사용할 수 있으며 성능은 CPU 성능에 의해 제한됩니다. 따라서 단일 인스턴스 CPU는 데이터 구조, 데이터 크기 및 서버 하드웨어 성능에 따라 초당 최대 5-6w QPS에 도달할 수 있습니다. 일상 환경의 QPS는 약 1-2w입니다.
간단한 거래 요구 사항을 지원하지만 업계에서 사용 시나리오가 거의 없고 미성숙하여 장점과 단점이 모두 있습니다.
Redis는 문자열 유형에서 더 많은 메모리를 소비합니다. dict(해시 테이블)를 사용하여 스토리지를 압축하여 메모리 소비를 줄일 수 있습니다.
:) 다음은 제가 개인적으로 추가한 내용입니다
Mc와 Redis는 모두 키-값 유형이므로 서로 다른 데이터 세트 간의 관계를 설정하는 데 적합하지 않으며 쿼리 검색에도 적합하지 않습니다. 예를 들어, redis 키 pattern의 일치 작업은 redis 성능에 재앙입니다.
모고디비
mogodb는 문서 데이터베이스입니다. 먼저 xml, json, bson 형태의 데이터를 저장할 수 있는 문서 데이터베이스에 대해 설명하겠습니다. 이러한 데이터는 자체 설명적이며 계층적 트리와 같은 데이터 구조를 나타냅니다. Redis는 해시를 사용하여 간단한 관계형 데이터를 저장할 수 있습니다.
mogodb는 json 형식의 데이터를 저장합니다.
적합한 시나리오: 이벤트 녹화, 콘텐츠 관리 또는 댓글 시스템과 같은 블로그 플랫폼.
Nosq에는 현재 많은 제품이 있으며, 건축가의 선택은 주로 다음 두 가지 요소에 의해 결정됩니다.
1) 애플리케이션 사용 시나리오에 적합합니다. 예를 들어 mogodb를 사용하는 데 더 적합하며 mc도 구현할 수 있습니다. (애플리케이션에서 데이터를 json으로 변환하여 저장하지만 일부 데이터를 업데이트하는 것이 불편합니다.)
2) 팀은 자신에게 익숙한 기술을 개발합니다. 예를 들어 팀에서 mc를 사용해 왔기 때문에 redis 대신 mc를 선택하는 것이 제한됩니다.
개발팀이 mogodb를 사용해 왔으며 kv nosq에 적합한 시나리오에서 mogodb를 계속 선택하는 중간에서 심각한 상황도 있습니다.
모든 사람에게 추천하는 책: <NoSQL Essence>
http://segmentfault.net/q/1010000002572713
Redis와 Memcache는 두 가지 캐싱 메커니즘으로 주로 데이터베이스 부담을 줄이고 액세스 속도를 향상시키는 데 사용됩니다. Redis는 캐시를 하드 디스크에 저장하고 컴퓨터를 다시 시작하여 계속 호출할 수 있습니다. Memcache에는 단일 기능과 높은 효율성으로 단순히 메모리에 캐시되는 기능도 많이 있습니다. mongoDB의 경우 이것은 단지 데이터베이스일 뿐입니다