APPEND key value

Contents

• 사용 가능한 버전 : 2.0.0 이상
• 시간 복잡도 : Redis는 문자열을 저장하기 위한 공간을 할당 할 때, 재 할당을 위해서 두배의 공간을 미리 할당한다. 따라서 (항상 그런건 아니겠지만) 시간 복잡도는 O(1)로 가정할 수 있다.

만약 key가 이미 존재하고 값이 string 이라면, string의 마지막에 value를 덧 붙인다(append). 만약 key가 없다면, key를 만들고 value를 설정한다. 이 경우 SET과 비슷하게 작동한다.

Interger 값 : 덧 붙인 후 전체 문자열의 길이

고정된 크기의 값을 시간 순으로 계속 쌓아야 할 경우, 유용하게 사용할 수 있다. 사이즈가 고정될 경우 문자열에서 특정위치의 값을 가져오는 건 어렵지 않다.

• STRLEN을 이용해서 몇 개의 값이 저장되어 있는지 확인할 수 있다.
• GETRANGE를 이용해서 문자열에서 임의 접근(random access)이 가능하다. 필요하다면 Redis 2.6에서 지원하는 Lua 스크립트 엔진을 이용해서 binary search를 수행할 수도 있다.
• SETRANGE를 이용해서 값을 업데이트 할 수도 있다.

이 패턴의 제약 사항은 오로지 추가 모드만 있다는 점이다. Redis는 string에 대한 trim을 지원하지 않기 때문에, 데이터의 삭제가 쉽지 않다. Time se series 데이터에서 삭제 작업이 흔하지 않기 때문에, 대게의 경우 큰 문제가 되진 않을 것이다.

키로 Unix time을 사용 하면, 저장되는 문자열의 크기를 작게 유지할 수 있다. 이 방법을 이용하면, 데이터를 분산하고 처리하기가 쉬워질 것이다. 예를들어 "2014년 11월 1일 00:00:00 부터 2014년 11월 1일 23:59:59초" 까지의 온도를 한 시간 단위 저장해야 한다고 가정해 보자. Key는 2014/11/1 00:00:00을 Unix time으로 변환한 "1414800000"이다. 값은 데이터를 저장한 Unix time + 현재 온도다. 현재 온도는 4자리로 했는데, 음수를 표현하기가 애매모호 해서 절대온도로 나타냈다. 예제에서는 01:00:00의 온도를 가져왔다. 283-273 이니 영상 10도가 되겠다. 값에도 unixtime을 넣은 이유는 데이터에 빵구가 날 경우 보정할 정보가 필요하기 때문이다.

Time Series 정보의 대표적인 예는 모니터링 데이터일 것이다. CPU 사용율이라든가 뭐 이런 것들 말이다. APPEND를 이용해서 RRD 스타일로 구축할 수 있을 것 같은데 흠.. Redis의 Rua 스크립트 엔진을 이용해서 구현할 수 있을지 생각을 해봐야 겠다.