Memcached vs Redis

	Memcached	Redis
출생	2003년	2009년
지향점	새로운 기능 보다 안정성과 최적화에 중점	다양한 기능 제공. 더 강력하지만 좀 더 복잡함
유사점	- in-memory 위에서 동작하는 key-value 스토리지로 둘다 noSQL에 속하는 데이터 관리 솔루션 - key-value 데이터 모델을 기반으로 동작 - 모든 데이터는 메모리 안에 있으며 캐시 관점에서 매우 유용 - 정렬에서 성능에 극적으로 영향을 끼침(select문에서 가장 많은 비용을 차지하는 order를 메모리로 접근하기 때문에 매우 빠름)
차이점	-  키의 이름 250바이트로 제한 - 캐시 값의 용량은 1메가바이트로 제한 - 오로지 문자열만(string) 캐시 가능 - 멀티 스레드 - 최소 알고리즘(LRU)를 사용하여 새 데이터와 크기가 비슷한 데이터를 임의로 제거 - lazy Eviction만 제공	- 캐싱한 콘텐츠를 미세하게 튜닝하거나 캐시의 지속성(유사시 데이터 백업의 의미) 및 전반적인 효율성 등을 조절 가능 - 키명과 값의 용량을 각각 512메가바이트까지 크게 사용 가능하며 그것들을 안전한 바이너리로 관리 - 5가지의 데이터 구조 형식을 취급(다양한 가능성 제시) - 해시를 이용해 오브젝트 필드와 값을 유니크하게 관리 가능 - global cache 방식 채택 - 싱글 스레드 - 데이터 축출 (Data eviction)(새 데이터를 위해 오래된 데이터를 축출하는) 메커니즘 사용 > 6가지의 정책 중 하나를 선택 - 서버가 저장하는 데이터가 불투명하지 않아 서버가이를 직접 조작할 수 있음 - 관리하는 데이터를 복제할 수 있음(장애 대비) - 사용량 및 비정상적인 동작을 모니터링하고 추적할 수 있는 수많은 매트릭스와 내성 명령을 제공
언제 사용?	- 작고 변하지 않는 데이터 (ex:HTML코드)를 캐싱할 때 내부 메모리가 복잡하지 않기 때문에 비교적 작은 메모리를 사용 - 멀티 스레드로 더 많은 계산 리소스를 제공하여 쉬운 수평적 확장 (redis도 3.0이후 이 기능 포함)	- 옆의 두 가지 사항을 제외한 모든 상황 - 대부분 싱글 스레드로서 데이터 손실없이 클러스터링(설정 및 운영이 비교적 복잡)을 통해 수평 확장이 가능
참고	https://brownbears.tistory.com/43 http://blog.leekyoungil.com/?p=200 https://ojava.tistory.com/70