查詢在Redis的多鍵我有redis的保持在以下格式優化通過節點
identifier:username:userid:categoryname
例如某些關鍵:
Blacklist:tomhanks:12345:movies
Blacklist:tomhanks:12345:music
Blacklist:micaheljordan:23456:sports
Blacklist:micaheljordan:23456:movies
現在有次我有可用的用戶名和我一起在某些情況下與我一起使用。但是,我不知道哪一個可用。根據API要求,我可以選擇其中任何一個。所以我需要查詢兩次 - 一次使用用戶名 - 其次使用用戶ID。例如:
例如: KEYS Blacklist:tomhanks:* & KEYS Blacklist:*:12345:*
然後合併結果並相應地將從其他API獲取的類別列入黑名單。
我使用的NodeJS查詢這個Redis的實例,因此,而不是查詢兩次,我決定使用節點JS
按node redis github example for multi command此頁面上的例子,我查詢Redis的實例multi exec
在以下格式
client.multi([
["keys", "Blacklist:tomhanks:*"],
["keys", "Blacklist:*:12345:*"]
]).exec(function (err, replies) {
console.log(replies.toString());
});
但最近我在Redis的檢查由slowlog,我發現列表的頂部,還有一些查詢的超時之間EXEC命令。雖然KEYS的數量只有10000個。
另外間歇我得到的console.log消息node_redis: no callback to send error: ERR EXEC without MULTI
POA:
- 使用集,而不是KEYS以下列格式
KEY: Blacklist:tomhanks -> movies, music KEY: Blacklist:123456 -> movies, music
- 或以某種方式重新構建,其具有2的第二鍵
Blacklist:*:12345:*
通配符,因此相對較重 建議的結構將是Blacklist:tomhanks:movies Blacklist:tomhanks:music Blacklist:12345:movies Blacklist:12345:music
由於每warning posted on this page about KEYS
Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using sets.
是使用SETS
比KEYS
一個更好的主意嗎?
是相同的用戶名在你的情況下?如果不是,你必須通過組合userid進行搜索來找到一個特定的用戶,這會使情況變得更糟。 –
是用戶名和特定用戶的用戶ID是唯一的 – swapnilsarwe