PostIT

[DB/Redis]Redis에 대해서 공부하기, Redis vs Ehcache vs Memcached 비교하며 파악하기 본문

DB/Redis

[DB/Redis]Redis에 대해서 공부하기, Redis vs Ehcache vs Memcached 비교하며 파악하기

shun10114 2017. 4. 17. 23:03

# Redis에 대해서 공부하기, Redis vs Memcached vs 비교하며 파악하기.


- 최근 수정일 : 2017.04.17



##1. 배경

  • 도입 배경은 Menu나 Message같이 반복적으로 DB에서 데이터를 로딩해야하는 부분이 자원낭비라는 생각을 하게 되었다. 이부분을 어떻게 해소할 수 있을까 고민하며 Cache라는 것을 접하게 되었고, Ehcache를 사용하였지만, Cache가 직접 관리되지 않는 어려움을 느끼게 되었다. 그래서 Bash에서 관리 할 수 있는 Redis를 이용하게 되었습니다.
  • 프로젝트를 진행하다보면 Cache를 통해 DB의 부하를 줄여야하거나, 정적인 Html 등의 Resource등을 관리하여 성능을 향상시켜야 할 때가 있다. 특히, Spring의 Ehcache가 쉽게 적용가능하며, 더 나아가 Memcache나 Redis를 Data structure store로서 사용하여 Cache를 관리할 수 있는데(Key value Store), 이부분에 더 학습이 필요할 것으로 생각되었습니다.



##2. 키워드


###Cache란?

캐시란 데이터를 임시로 저장해두는 장소를 말한다. 

    • 사용자가 요구한 웹 페이지는 하드디스크 내의 캐시 디렉토리에 저장된다. 이런 방법으로, 사용자가 최근에 열어본 페이지로 다시 돌아왔을 때 브라우저는 시간을 줄이고 네트워크(통신)에 추가 부담을 덜기 위해, 원래의 서버에서 정보를 찾아오는 대신에 캐시로부터 데이터를 가져오는 것이다.
    • DB에 접속하지 않고 DB데이터를 갖고있어 DB의 부하를 줄여줄 수도 있다.
    • 컴퓨터는 운영상의 수준에 따라 몇가지 캐시들을 유지하는데, 캐시 메모리나 디스크 캐시 등이 바로 캐시가 저장되는 곳이다. 또한 캐시는 같은 정보를 여러 개의 서버에 분산시켜놓고 주기적으로 최신의 것으로 갱신시키는 방법을 통해 인터넷 정보에 대해서도 구현될 수 있다.

###Memcache

Memcached는 2003년 LiveJournal 웹 사이트에서 Brad Fitzpatrick이 개발했습니다. 그 후 Memcached는 C로 재 작성되었으며 (원래의 구현은 Perl로 작성되었습니다) 공개 된 도메인에 배치되어 현대 웹 응용 프로그램의 초석이되었습니다. Memcached의 현재 개발은 새로운 기능을 추가하는 것이 아니라 안정성과 최적화에 초점을두고 있습니다.


###Redis

Redis는 2009년 Salvatore Sanfilippo가 창안했으며, Sanfilippo는 현재이 프로젝트의 주 개발자로 남아 있습니다. 때로는, Redis를 "Memcached on steroids"로 묘사됩니다. Redis는 Memcached를 사용하여 얻은 교훈으로 Redis의 일부가 작성된 것을 생각하면 놀라울 일도 아닙니다. 하지만, Redis는 Memcached보다 더 많은 기능을 가지고 있으므로 강력하고 유연합니다.


Redis와 Memcache가 인기있는 이유는, 매우 효과적 일뿐만 아니라 비교적 간단하기 때문입니다. Memcached 또는 Redis를 시작하는 것은 개발자가 쉽게 적용 할 수 있으며, 설정 및 응용 프로그램 작업을 적용하는 데 몇 분 밖에 걸리지 않습니다. 따라서 적은 시간과 노력으로 성능에 즉각적인 영향을 미칠 수 있습니다. 



##3. 내용


###Memcache > Redis(Memcache의 장점)

1. Memcached는 HTML과 같이 상대적으로 작고 정적인 데이터를 캐싱 할 때 선호 될 수 있습니다. Memcached의 메모리 관리는 Redis만큼 정교하지는 않지만, 메타 데이터에 대한 메모리 리소스를 비교적 적게 소비하기 때문에 가장 간단한 사용하기에는 Redis보다 더 효율적입니다. 특히, Memcached에서 지원하는 유일한 데이터 형식인 문자열을 따로 처리 할 필요가 없으므로 읽기 전용 인 데이터를 저장하는 데 이상적입니다.


2. Memcached가 Redis 보다 갖는 이점 두번째는 확장입니다. Memcached는 멀티 스레드이므로 더 많은 계산 리소스를 제공하여 Redis보다 쉽게 확장 할 수 있지만 일관된 해싱 사용 여부에 따라 캐시 된 데이터의 일부 또는 전부를 잃게됩니다. 이에 반해 Redis는 대부분 싱글 스레드로서 데이터 손실없이 클러스터링을 통해 수평 확장이 가능합니다. 클러스터링은 효과적인 확장 솔루션이지만 설정 및 운영이 비교적 복잡합니다.


###Redis > Memcache(Redis의 장점)

1. Redis의 우수성은 캐시 관리의 거의 모든 측면에서 분명합니다. 캐시는 메모리에서 오래된 데이터를 삭제하여 새로운 데이터를 저장할 공간을 만들기 위해 데이터 축출 (Data eviction)이라는 메커니즘을 사용합니다. Memcached의 데이터 제거 메커니즘은 최근에 사용 된 최소 알고리즘(LRU)을 사용하며 새 데이터와 크기가 비슷한 데이터를 임의로 제거합니다.


반대로 Redis는 Eviction에 대한 세분화 된 제어를 허용하여 여섯 가지 Eviction 정책 중 하나를 선택할 수 있습니다. Redis는 또한 메모리 관리 및 퇴거 후보 선택에보다 정교한 접근법을 사용합니다. Redis는 더 많은 공간이 필요하거나 사전에 데이터가 제거되는 경우에만 lazy and active Eviction을 지원합니다. 반면에 Memcached는 lazy Eviction만 제공합니다.

[LRU-cache](https://redis.io/topics/lru-cache)    


6개의 Eviction 정책

    • noeviction : 메모리 제한에 도달하여 클라이언트가 더 많은 메모리를 사용할 수있는 명령을 실행하려고 할 때 오류를 리턴합니다 (대부분의 쓰기 명령, DEL 및 몇 가지 예외)
    • allkeys-lru : 가장 최근에 사용되지 않은 (LRU) 키를 먼저 제거하여, 새 데이터를위한 공간을 추가합니다.
    • volatile-lru : 가장 최근에 사용되지 않은 (LRU) 키와 만료 집합이있는 키를 먼저 제거하여, 새 데이터 공간을 추가합니다.
    • Allkeys-random : 새 데이터를 추가 할 수 있도록 임의의 키를 제거합니다.
    • volatile-random : 새 데이터를 추가 할 공간을 만들기 위해 무작위 키를 제거하지만 만료 세트가있는 키만 제거합니다.
    • volatile-ttl : 새 데이터를 저장할 공간을 만들기 위해 만료 집합이있는 키만 제거하고 TTL (Short Time to Live) 키를 먼저 제거합니다.


2. Redis는 캐시 할 수있는 개체에 대해 훨씬 뛰어난 유연성을 제공합니다. Memcached는 Key name을 250 bytes로 제한하고 일반 문자열로만 작동하지만, Redis는 키 이름과 값을 각각 512MB로 허용하며 이진 안전합니다. 또한 Redis는 선택할 수있는 다섯 가지 기본 데이터 구조를 갖추고 있으며 캐시 된 데이터를 지능적으로 캐싱하고 조작하여 응용 프로그램 개발자에게 다양한 가능성을 제시합니다.
[Commands](https://redis.io/commands)


3. Redis의 또 다른 중요한 이점은 서버가 저장하는 데이터가 불투명하지 않기 때문에 서버가이를 직접 조작 할 수 있다는 것입니다. Redis에서 사용할 수있는 180 개 이상의 명령 중 상당 부분은 서버 측 루아 스크립팅을 통해 데이터 처리 작업과 데이터 저장소 자체에 로직을 포함하는 데 사용됩니다. 이러한 기본 제공 명령 및 사용자 스크립트를 사용하면 네트워크를 통해 다른 시스템으로 데이터를 보내 처리 할 필요없이 Redis에서 직접 데이터 처리 작업을 처리 할 수 있습니다.

[Commands](https://redis.io/commands)


4. Redis는 관리하는 데이터를 복제 할 수도 있습니다. 복제는 장애를 견딜 수 있고 응용 프로그램에 중단없는 서비스를 제공 할 수있는 고 가용성 캐시 설정을 구현하는 데 사용할 수 있습니다. 캐시 오류는 사용자 경험 및 응용 프로그램 성능에 미치는 영향 측면에서 응용 프로그램 오류에 약간 미치지 만 대부분의 경우 캐시의 내용과 서비스 가용성을 보장하는 입증 된 솔루션을 보유하고 있습니다.

[Replicate](https://redis.io/topics/replication)


5. 마지막으로 중요한 것은 운영 가시성 측면에서 Redis는 사용량 및 비정상적인 동작을 모니터링하고 추적 할 수있는 수많은 메트릭스와 풍부한 내성 명령을 제공합니다. 데이터베이스의 모든 측면에 대한 실시간 통계, 실행중인 모든 명령의 표시, 클라이언트 연결의 나열 및 관리 - Redis에는 그 이상이 있습니다.

[Monitor](https://redis.io/topics/latency-monitor)


6. 개발자가 Redis의 지속성 및 메모리 내 복제 기능의 효율성을 인식 할 때, 대개 고속 데이터를 분석 및 처리하고 보조 (종종 더 느린) 데이터베이스가 있는 동안 사용자에게 응답을 제공하는 첫 번째 응답자 데이터베이스로 사용합니다. 어떤 일이 일어 났는지에 대한 기록을 유지합니다. 이러한 방식으로 사용될 경우 Redis는 분석 사용 사례에 이상적 일 수 있습니다.


Redis 더 알아보기



##4. 추가 정보



 

Name

Ehcache

Memcached 

Redis

Description

계층적 스토리지 옵션이있는 

널리 채택  Java 캐시  

 근본적인 캐싱을 위한 

n-메모리 Key-Value Store

데이터베이스캐시  

메시지 브로커로사용되는

In Memory Data Structure Store

Database model

Key-value store

Key-value store

Key-value store

Website

ehcache.org

www.memcached.org

redis.io

Developer

Terracotta Inc

owned by Software AG

Danga Interactive

Salvatore Sanfilippo

Initial release

2009

2003

2009

Cloud-based

no

no

no

Implementationlanguage

Java

C

C

Server operating systems

All OS with a Java VM

FreeBSD
Linux
OS X
Unix
Windows

BSD
Linux
OS X
Windows

Data scheme

schema-free

schema-free

schema-free

Typing

yes

no

partial

XML support

no

no

Secondary indexes

no

no

no

SQL

no

no

no

APIs and other 

access methods

JCache

Proprietary protocol

proprietary protocol

Supported 

programming

languages

Java

.Net
C
C++
ColdFusion
Erlang
Java
Lisp
Lua
OCaml
Perl
PHP
Python
Ruby

C
C#
C++
Clojure
Crystal
D
Dart
Elixir
Erlang
Fancy
Go
Haskell
Haxe
Java
JavaScript (Node.js)
Lisp
Lua
MatLab
Objective-C
OCaml
Perl
PHP
Prolog
Pure Data
Python
R
Rebol
Ruby
Rust
Scala
Scheme
Smalltalk
Tcl

Server-side scripts

no

no

Lua

Triggers

yes

no

no

Partitioning methods

Sharding

none

Sharding

Replication methods

yes

none

Master-slave replication

MapReduce

no

no

no

Consistency concepts

Eventual Consistency

Foreign keys

no

no

no

Transaction concepts

yes

no

Optimistic lockingatomic 

execution of commands 

blocks and scripts

Concurrency

yes

yes

yes

Durability

yes

no

yes

In-memory capabilities

yes

yes

User concepts

no

yes

Simple password-based 

access control

 

 

 

 

##5. 결론

    • 추가 작성 예정!~


##5. 참조사이트

- http://www.infoworld.com/article/3063161/application-development/why-redis-beats-memcached-for-caching.html

- https://db-engines.com/en/system/Ehcache%3bMemcached%3bRedis
- https://redis.io



'DB > Redis' 카테고리의 다른 글

[Redis/DB] Redis에 대해서 - 퍼옴  (0) 2016.12.13
Comments