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

首先，我相信你的意思是说哈希而不是设定;设定的数据结构不适合您所描述的内容。

您拥有的两个选项是：

哈希：一个字符串到字符串的数据映射。如果您想象键值是JSON数据，那么您作为哈希的消息将如下所示：
```
msg:1 = {
  "sender": "12",
  "text":   "hello there",
  "date":   "6278127367",
  "recpnt": "88223",
  "viewed": "false"
}
```
您会注意到您可以清楚地看到哪些值映射了什么键;数据有一些结构。 Hash look up也是不变的时间。
列表：字符串的链接列表。再次，将您的数据想象为JSON：
```
msg:1 = ["12", "hello there", "6278127367", "88223", "false"]
```
现在还不清楚哪个值映射到哪个字段，是吗？您必须跟踪列表的哪个索引存储哪些信息，这会增加应用程序的复杂性。此外，accessing an individual field不再是固定时间。

从上述两点来看，哈希似乎更合适。

但是在选择哈希表时对空间的影响是什么？以下是使用上述消息的哈希和列表（使用DEBUG OBJECT <key>找到）的大小：

列表：49个字节
哈希：86字节（~1.75x）

邮件只有11个字符。那个tweet-sized (116 characters)呢？

列表：143字节
哈希：174字节（~1.22x）

是的，存储的哈希值会更大，但它的大小可能不会是普通情况的两倍。

所以尽管有点大，但我仍然认为 hash 是正确的数据结构（当然，除非你增加的托管账单会破坏你）。

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

1 个答案: