redis - 哈希比列表占用更多内存？

Question

请帮助选择如何存储消息:

1)

SET msg:1 sender 12
SET msg:1 text "hello there"
SET msg:1 date 6278127367
SET msg:1 recpnt 88223
SET msg:1 viewed false
SET msg:2 sender 102
SET msg:2 text "blablabla"
SET msg:2 date 6278127643
SET msg:2 recpnt 523
SET msg:2 viewed false
SET msg:3 sender 16
SET msg:3 text "nice weather isntit"
SET msg:3 date 6278127432
SET msg:3 recpnt 48781
SET msg:3 viewed true

2)

LPUSH msg:1 12 "hello there" 6278127367 88234 false
LPUSH msg:2 523 "blablabla" 6278127367 4323 false
LPUSH msg:3 16 "nice weather isn't it" 6278127234 223 true
LPUSH fields sender text date recpnt viewed

SET 似乎比 LIST 更容易使用，但 Redis 会存储每条消息的字段名称，从而使内存使用量加倍吗？

Answer 1

首先，我相信你的意思是说散列而不是集合；集合数据结构不适合您所描述的内容。

您接下来的两个选择是:

1. 哈希:数据的字符串到字符串映射。如果您将键值想象为 JSON 数据，则作为哈希的消息将如下所示:

   msg:1 = {
     "sender": "12",
     "text":   "hello there",
     "date":   "6278127367",
     "recpnt": "88223",
     "viewed": "false"
   }
   

   您会注意到，您可以清楚地看到哪些值与哪些键对应；数据具有某种结构。 Hash look up也是常数时间。

2. 列表:字符串的链接列表。同样，将您的数据想象成 JSON:

   msg:1 = ["12", "hello there", "6278127367", "88223", "false"]
   

   现在不清楚什么值映射到什么字段，是吗？您必须跟踪列表的哪个索引存储了哪些信息，这会增加您的应用程序的复杂性。另外，accessing an individual field不再是常数时间。

从以上两点来看，hash似乎更合适。

但是选择哈希表对空间有什么影响呢？这是使用上述消息的散列和列表的大小(使用 DEBUG OBJECT <key> 找到):

• 列表:49 字节
• 哈希:86 字节 (~1.75x)

消息只有 11 个字符。那一个是tweet-sized (116 characters)呢？ ？

• 列表:143 字节
• 哈希:174 字节 (~1.22x)

是的，存储的哈希值会更大，但在一般情况下它的大小可能不会翻倍。

因此，尽管有点大，但我仍然相信 hash 是正确的数据结构(当然，除非您增加的托管费用会让您破产)。