Redis에서 이벤트 타임 라인 저장

Redis의 타임 라인에 이벤트 목록을 저장하고 싶습니다. 나는 1970 년 이래로 빠른 검색과 범위 검색을 허용하는 스코어로서 초 단위의 정렬 된 세트를 생각하고있다.Redis에서 이벤트 타임 라인 저장

문제는 몇 가지 키 (약 3 개 정도)를 사용하여 이러한 이벤트 각각을 개체로 나타내므로 정렬 된 ID 집합을 저장할 것입니다. 그러면 응용 프로그램은 다음을 기반으로 해시를 조회합니다. 신분증.

그래서 대화는 다음과 같이 갈 것이다 :

> ZRANGEBYSCORE events start end 
1) "16" 
2) "17" 
> HGETALL events:16 
1) "key1" 
2) "val1" 
... 
> HGETALL events:17 
...

정리 또는 각 결과에 대한 별도의 호출을 응용 프로그램을 피할 것이다 일을 할 수있는 더 좋은 방법이있다. 이 오버 헤드를 피하기 위해 redisation 서버 측에서 모든 작업을 수행 할 수 있습니까? 심지어 큰 문제입니까?

추신. 노드 클라이언트를 사용하고 있지만 내 질문은 다른 언어에도 적용됩니다.

출처

2011-12-29 Adam

로를 검색 할 수 있습니다. 따라서 zset은 이러한 객체에 대한 참조를 저장하는 대신 직렬화 된 객체를 저장할 수 있습니다. 노드를 사용하면 JSON을 쉽게 사용할 수 있습니다.

이제는 현재 구조를 유지해야하는 경우 (예를 들어 일부 개체가 여러 zsets에 공유되기 때문에) 명령이 아닌 루팅 (rountrip)이라는 용어로 생각해야합니다. Redis에서 비용이 많이 드는 것은 O (1) 명령 자체의 실행이 아니라 왕복입니다.

HGETALL은 가변 매개 변수를 지원하지 않습니다 (즉, 하나의 해시 객체 만 검색 할 수 있음). 하지만 Redis는 파이프 라인 된 명령을 처리하는 데 상당히 뛰어 났으며 노드의 비동기 특성으로 인해 node_redis 드라이버에서 특히 쉽게 수행 할 수 있습니다. 따라서 귀하의 예에서는 ZRANGEBYSCORE를 수행하는 첫 번째 왕복과 모든 HGETALL 명령을 수행하는 두 번째 왕복 (즉, 두 번째 왕국을 발행하기 전에 첫 번째 HGETALL 명령의 결과를 기다리지 말 것) 왕복 왕복 2 개만 필요합니다. 그것은 꽤 효율적 일 것입니다.

현재 Redis 버전 (2.4)에서는 두 번째 왕복을 제거 할 방법이 없습니다.

출처

2011-12-30 10:13:23

우리는 이와 비슷한 방식으로 비슷한 것을 사용합니다. 또한 Redis 스크립팅 브랜치를 사용하면 한 번에이 작업을 수행 할 수 있습니다. – tddmonkey

이 정보를 한 필드에 저장하는 데는 단점이 있습니까? rdbms 필드에 csv를 저장하는 것과 비슷합니까? 속도에 대한 단점입니까? – Adam

개체가 작을 때 실제적인 단점은 없습니다. 객체가 더 크고 부분 업데이트를 지원하거나 다양한 컨테이너의 객체를 공유하려는 경우 단점이 있습니다. csv에 대한 언급과 관련하여 모든 데이터베이스 시스템은 행 (DB2, PostgreSQL, Oracle 등)을 직렬화해야합니다. 대부분 가변 길이 데이터 (구분 기호 또는 크기 접두어 포함)를 지원합니다. 그들이 사용하는 형식은 최적화 된 바이너리이지만 복잡성의 관점에서 보면 직렬화 비용은 단순한 csv 행에서 얻을 수있는 것과 다르지 않습니다. –

당신은 객체를 캐릭터 라인 화하고 stringwith JSON.stringify()로 저장하고 확실한 솔루션은 값 대신에 참조로 작업하여 작업하는 것입니다 JSON.parse()

출처

2011-12-30 02:25:42 fent

Redis에서 이벤트 타임 라인 저장

답변

관련 문제