소프트웨어 프로그래밍에서 가장 먼저 다루는 데이터 스트럭처는 비트, 배열, 스트링, 리스트다. 단순해서 배우고 응용하기 쉽고, 다른 데이터 스트럭처를 이해하기 위한 기본이 되기 때문이다. 단점은 단순한 만큼 응용범위도 넓지 않다는데 있다.
Sets는 좀 더 복잡하고 그 만큼 더 다양한 응용을 할 수 있다.
Sets는 key에 하나 이상의 value를 가지는 데이터 스트럭쳐다. 값은 정렬되지는 않지만 데이터 중복을 허용하지 않는다. SADD 명령으로 key에 value를 추가 할 수 있다. 그리고 SMEMBERS명령으로 value들을 가져올 수 있다.
Set도 List와 마찬가지로 string을 저장한다는 점에서 유사점이 있다. 하지만 List와는 달리 해시 테이블을 사용해서 모든 문자열을 고유하게 유지한다. Set은 List와 다르게 순서가 없기 때문에 아이템을 POP 하거나 Push 할 수 없다. 대신 SADD와 SREM을 이용해서 아이템을 추가하거나 삭제한다. 또한 SISMEMBER로 찾는 아이템이 있는지 확인 할 수 있고 SMEMBERS로 전체 아이템 목록을 가져올 수 있다.
시간 복잡도(time Complexity)관점에서 살펴보자. List는 내부적으로 링크드 리스트다. 따라서 List의 크기와 상관 없이 처음과 마지막에 아이템을 추가하는 것은 O(1)이 된다. 하지만 목록의 중간에 있는 아이템을 찾는데는 시간이 걸릴 수 있다. 이 작업은 기본적으로 O(n)이다. 반면 SET은 아이템 추가, 삭제, 확인에 O(1)복잡도를 가진다.
만약 자료구조에 임의의 아이템이 있는지를 확인하는 작업이 요구된다면 List가 아닌 Set을 사용하도록하자. 그밖에 Union, Diff, Intersection 같은 연산을 수행 할 수 있는 것도 장점이다. 가장 큰 장점은 정렬된 set을 만들 수 있다는 점이다. 이 내용은 따로 다루도록 하겠다.
아래는 SET 데이터 스트럭처를 위해서 사용 할수 있는 명령들이다.
Redis는 Sorted Set을 지원한다. "정렬을 위한 필드를 제공하고 여기에 정렬 값을 설정하는 것으로 아이템을 정렬 할 수 있다"는 점을 제외하면 set과 동일하다. Sorted set에서의 아이템 추가, 삭제, 확인의 시간 복잡도는 O(1)이다. 하나의 set당 최대 2^32 - 1(약 40억)개의 아이템을 저장 할 수 있다.
ZADD 명령으로 아이템을 삽입할 수 있다.
1
ZADD key [NX|XX] [CH] [INCR] score member [score member ...]
Sorted Set을 이용해서, 카테고리별 인기 아이템을 서비스 할 수 있을 것이다. 개인화된 유저 추천 서비스를 만든다고 가정해 보자. 아래 그림을 보자.
유저 id를 key로 해서 방문한 카테고리이름과 방문횟수를 sorted set 형태로 저장을 한다. 간단하게 INCR을 하는 것으로 유저가 선호하는 카테고리 정보를 저장할 수 있을 것이다. 위 그림에서 3210 유저가 선호하는 카테고리는 "beauty"다. 그리고 각 카테고리 별로 인기있는 제품의 sorted set을 만든다. 위 그림에서 "beauty"카테고리의 인기 상품은 Fragrance와 Skincare다 그러므로 3120 유저에게는 Fragrance와 Skincare 제품을 추천하면 될 것이다. 물론 실제 서비스에서는 유저의 나이, 성별, 세부 제품별로 더 정교한 Set을 만들어야 할 것이다.
Contents
1. Sets 과 Sorted sets
2. SET의 사용
3. Set을 이용한 태그 검색
4. Sorted Set
5. 소셜 그래프
6. SET을 이용한 친구 추천 서비스 구성
7. Sorted SET을 이용한 가중치 적용 태그 추천 서비스 구성
1. Sets 과 Sorted sets
2. SET의 사용
3. Set을 이용한 태그 검색
4. Sorted Set
5. 소셜 그래프
6. SET을 이용한 친구 추천 서비스 구성
7. Sorted SET을 이용한 가중치 적용 태그 추천 서비스 구성
Recent Posts
Archive Posts
Tags