Redis
 sql >> база данни >  >> NoSQL >> Redis

Redis:разклоняване на новинарски канали в списък или сортиран набор?

Да, сортираните комплекти са много бързи и мощни. Те изглеждат много по-подходящи за вашите изисквания, отколкото SORT операции. Времевата сложност често се разбира погрешно. O(log(N)) е много бърз и се мащабира добре. Използваме го за десетки милиони членове в един сортиран набор. Извличането и вмъкването е под милисекунда.

Използвайте ZRANGEBYSCORE key min max WITHSCORES [LIMIT offset count] за да получите резултатите си.

В зависимост от това как съхранявате клеймите за време като „резултати“, ZREVRANGEBYSCORE може да е по-добър.

Малка забележка относно времевите марки:Сортиран набор SCORES които не се нуждаят от десетична част, трябва да използват 15 цифри или по-малко. Така че SCORE трябва да остане в диапазона -999999999999999 до 999999999999999. Забележка:Тези ограничения съществуват, защото Redis сървърът всъщност съхранява резултата (float) като представяне на redis-низ вътрешно.

Затова препоръчвам този формат, преобразуван в Zulu Time:-20140313122802 за втора точност. Можете да добавите 1 цифра за 100 мс точност, но не повече if не искате да губите прецизност. Между другото, все още е float64, така че загубата на прецизност може да е добре в някои сценарии, но вашият калъф се вписва в диапазона на „перфектна точност“, така че това е, което препоръчвам.

Ако данните ви изтекат в рамките на 10 години, можете също да пропуснете трите първи цифри (CCY от CCYY), за да постигнете точност от 0,0001 секунди.

Предлагам отрицателни резултати тук, така че можете да използвате по-простия ZRANGEBYSCORE вместо REV един. Можете да използвате -inf като начален резултат (минус безкрайност) и LIMIT 0 100 за да получите първите 100 резултата.

Два сортирани набора members (или 'keys' но това е двусмислено, тъй като сортираният набор също е ключ сам по себе си) може да споделя score , това не е проблем, резултатите са в рамките на идентичен score са по азбучен ред.

Надявам се това да помогне, TW

Редактиране след чат

ОП искаше да събира данни (с помощта на ZSET ) от различни ключове (GET /SET или HGET /HSET ключове). JOIN може да направи това вместо вас, ZRANGEBYSCORE не може. Предпочитаният начин да направите това е прост Lua скрипт. Скриптът Lua се изпълнява на сървъра. В примера по-долу използвам EVAL за простота, в производството ще използвате SCRIPT EXISTS , SCRIPT LOAD и EVALSHA . Повечето клиентски библиотеки имат вградена логика на счетоводството, така че да не качвате скрипта всеки път.

Ето един example.lua :

local r={}
local zkey=KEYS[1]
local a=redis.call('zrangebyscore', zkey, KEYS[2], KEYS[3], 'withscores', 'limit', 0, KEYS[4])
for i=1,#a,2 do
  r[i]=a[i+1]
  r[i+1]=redis.call('get', a[i])
end
return r

Използвате го така (необработен пример, некодиран за производителност) :

redis-cli -p 14322 set activity:1 act1JSON
redis-cli -p 14322 set activity:2 act2JSON
redis-cli -p 14322 zadd feed 1 activity:1
redis-cli -p 14322 zadd feed 2 activity:2 

redis-cli -p 14322 eval '$(cat example.lua)' 4 feed '-inf' '+inf' 100

Резултат:

1) "1"
2) "act1JSON"
3) "2"
4) "act2JSON"



  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. gke не може да деактивира Transparent Huge Pages... разрешението е отказано

  2. как да убия неактивни клиенти на redis

  3. redis - Използване на хешове

  4. Как мога да изчистя всички екземпляри от тип X в ServiceStack Redis Client

  5. Използване на StackExchange.Redis в ASP.NET Core контролер