여러 HashSet 저장소를 사용할 수 있습니다. 각 Weibo는 HashSet의 하위 키일 뿐입니다. HIncrBy 명령을 사용하여 좋아요 수를 늘릴 수 있습니다. 각 HashSet의 키가 100을 초과하지 않도록 TID를 블록으로 나눕니다. 공식 문서에 따르면 HashSet은 내부 요소가 100개 미만일 때 선형 저장 및 스캐닝을 사용하며 이는 동일한 데이터 규모의 트리 구조에 비해 더 효율적이고 메모리를 절약합니다.
예: TID가 123456인 Weibo는 z:1234의 HashSet에 존재하며 해당 키는 56입니다. 최신 Weibo도 활발하게 활동한다고 가정하면 대부분의 경우 소수의 HashSet만 호출되므로 CPU 캐시에 매우 친화적입니다.
좋아하는 사용자를 관리하고 싶다면 데이터 형식을 맞춤설정할 수 있습니다. 사용자 수가 적은 경우 전체 사용자 목록을 HashSet의 값 필드에 포함시킵니다. 예를 들어 사용자가 50명이 넘으면 이들을 세트로 분리하고 해당 세트의 키를 HashSet에 저장합니다. 예:
으아악
대부분의 Weibo 사용자는 좋아요 수가 적기 때문에 HashSet은 전역 스페이스 키를 많이 절약할 수 있습니다(전역 키는 HashSet 키보다 더 많은 메모리를 소비합니다).
@속옷 판매 및 온라인 접속에 대한 답변:
내부 퀵 정렬을 사용하는 경우 사용자 50명의 수동 정렬 효율성은 매우 높습니다. 왜냐하면 이 데이터 규모에서는 데이터의 컴팩트한 저장으로 인한 캐시 친화성이 수동 정렬과 비교하여 Redis ZSet에서 가져온 개선 사항보다 훨씬 낫기 때문입니다. 이를 좋아하는 사용자가 승격된 후 알고리즘의 시간 복잡도를 보장하기 위해 자동으로 set 또는 zset에 적응합니다. 여전히 효율성이 걱정된다면 정렬된 UID 목록을 다시 HashSet의 값으로 다시 작성하고 나중에 데이터 변경이 없으면 직접 사용할 수 있습니다.
세트를 사용할지 zset을 사용할지는 여전히 포스터의 요구 사항에 따라 다릅니다. set에 멤버를 추가하는 복잡도는 O(1)이고 zset에 O(log N)이지만 set에는 정렬 기능이 없습니다.
UID마다 저장해야 하는 걸까요, 아니면 시나 웨이보가 하는 일이라고 생각하는 걸까요? 대부분의 경우 모든 사람은 숫자에만 주의를 기울입니다. 그렇다면 숫자를 사용하여 {tid->count}
를 저장하세요.
저장해야 하는 경우에는 {tid->set(uid)}를 사용하여 저장하는 것을 권장합니다
최적화는 임계값을 설정할 수 있다는 것입니다. 예를 들어 100명이 넘는 사람이 좋아하면 더 이상 아무것도 추가하지 않고 숫자만 추가하면 됩니다(물론 다른 {를 저장해야 함). tid->count}). 웨이보에는 좋아요가 10,000개 이상 있기 때문에 좋아요를 누른 사람을 일일이 클릭하는 사람은 아무도 없습니다. .
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
여러 HashSet 저장소를 사용할 수 있습니다. 각 Weibo는 HashSet의 하위 키일 뿐입니다. HIncrBy 명령을 사용하여 좋아요 수를 늘릴 수 있습니다. 각 HashSet의 키가 100을 초과하지 않도록 TID를 블록으로 나눕니다. 공식 문서에 따르면 HashSet은 내부 요소가 100개 미만일 때 선형 저장 및 스캐닝을 사용하며 이는 동일한 데이터 규모의 트리 구조에 비해 더 효율적이고 메모리를 절약합니다.
예: TID가
123456인 Weibo는z:1234의 HashSet에 존재하며 해당 키는 56입니다. 최신 Weibo도 활발하게 활동한다고 가정하면 대부분의 경우 소수의 HashSet만 호출되므로 CPU 캐시에 매우 친화적입니다.좋아하는 사용자를 관리하고 싶다면 데이터 형식을 맞춤설정할 수 있습니다. 사용자 수가 적은 경우 전체 사용자 목록을 HashSet의 값 필드에 포함시킵니다. 예를 들어 사용자가 50명이 넘으면 이들을 세트로 분리하고 해당 세트의 키를 HashSet에 저장합니다. 예:
으아악대부분의 Weibo 사용자는 좋아요 수가 적기 때문에 HashSet은 전역 스페이스 키를 많이 절약할 수 있습니다(전역 키는 HashSet 키보다 더 많은 메모리를 소비합니다).
@속옷 판매 및 온라인 접속에 대한 답변:
내부 퀵 정렬을 사용하는 경우 사용자 50명의 수동 정렬 효율성은 매우 높습니다. 왜냐하면 이 데이터 규모에서는 데이터의 컴팩트한 저장으로 인한 캐시 친화성이 수동 정렬과 비교하여 Redis ZSet에서 가져온 개선 사항보다 훨씬 낫기 때문입니다. 이를 좋아하는 사용자가 승격된 후 알고리즘의 시간 복잡도를 보장하기 위해 자동으로 set 또는 zset에 적응합니다. 여전히 효율성이 걱정된다면 정렬된 UID 목록을 다시 HashSet의 값으로 다시 작성하고 나중에 데이터 변경이 없으면 직접 사용할 수 있습니다.
세트를 사용할지 zset을 사용할지는 여전히 포스터의 요구 사항에 따라 다릅니다. set에 멤버를 추가하는 복잡도는 O(1)이고 zset에 O(log N)이지만 set에는 정렬 기능이 없습니다.
LS가 데이터처럼 저장하기 위해 HASH를 사용하는 것은 권장하지 않습니다. 왜냐하면 정렬할 수 있는 방법이 없기 때문입니다(필요하다면. 꼭 필요하다고 생각합니다)
현재 이렇게 처리하고 있습니다.
ZSET에서 주문한 세트를 저장용으로 사용할 수 있습니다. 이론적으로 ZSET에는 100,000명 이내의 숫자가 없습니다. 즉, Weibo를 좋아하는 사람의 수는 100,000명 이내입니다(이것은 불가능합니다). 으아악
흠, 또 PS!!!
Weibo와 같은 데이터를 저장하기 위해 NOSQL과 같은 데이터베이스를 사용해야 하는 경우 다음과 같이 저장할 수 있습니다.).으아악
다시 말씀드리지만, Weibo 댓글도 비슷한 방식으로 저장됩니다. $redis KEYS 이름에 동의하면 됩니다.c:<댓글 ID> 다음과 같이 Weibo 데이터와 연결하는 방법:
t:$tid:comments:scores(ZSET 타임스탬프 댓글 ID);
데이터 조회 시 PIPELINE을 이용하면 훨씬 편리합니다.
마지막으로 NOSQL과 같은 데이터베이스의 KEY가 올바르게 설정되어야 합니다.UID마다 저장해야 하는 걸까요, 아니면 시나 웨이보가 하는 일이라고 생각하는 걸까요? 대부분의 경우 모든 사람은 숫자에만 주의를 기울입니다. 그렇다면 숫자를 사용하여 {tid->count}
저장해야 하는 경우에는 {tid->set(uid)}를 사용하여 저장하는 것을 권장합니다
최적화는 임계값을 설정할 수 있다는 것입니다. 예를 들어 100명이 넘는 사람이 좋아하면 더 이상 아무것도 추가하지 않고 숫자만 추가하면 됩니다(물론 다른 {를 저장해야 함). tid->count}). 웨이보에는 좋아요가 10,000개 이상 있기 때문에 좋아요를 누른 사람을 일일이 클릭하는 사람은 아무도 없습니다. .