Question

我想用四列和八十千排载数据在《Redis》上的 MySQL, 这样我就可以减少取货延误。

然而,当我试图加载所有数据时,它会变大五倍。

原始数据是 3gb (当导出到 csv 格式时), 但当我在 Redis 上加载它们时, 需要15GB... 它对我们系统来说太大了.

我还尝试过不同的数据类型

1) table_name:row_number:column_name -> string 2) table_name:row_number -> hash

但它们都承受了太多。

我漏掉了什么吗?

(加)加)

我的数据有 4 col - (用户 ID (pk), 计数, 创建时间和日期)

Answer 1

最高效的存储方式是存储作为json阵列的值, 并分割您的密钥, 这样您就可以用一个编码为散列的拉链存储它们。

Encode your data using say json array, so you have key=value pairs like user:1234567 -> [21, 25-05-2012 , 14-06-2010 ].
Split your keys into two parts, such that the second part has about 100 possibilities. For example, user:12345 and 67
Store this combined key in a hash like this hset user:12345 67 <json>
To retrieve user details for user id 9876523, simply do hget user:98765 23 and parse the json array
Make sure to adjust the settings hash-max-ziplist-entries and hash-max-ziplist-value

Instagram写了一篇很棒的博客,解释这个技术 ,所以我将不解释为什么这是记忆效率高的原因。

相反,我可以告诉你这种技术的缺点。

You cannot access or update a single attribute on a user; you have to rewrite the entire record.
You d have to fetch the entire json object always even if you only care about some fields.
Finally, you have to write this logic on splitting keys, which is added maintenance.

和往常一样, 这是一个权衡。确定您的访问模式, 并查看这种结构是否合理。否则, 您必须购买更多的内存。

Answer 2

+1 可能在此情况下释放一些内存的 +1 想法- 键拉链, 以碎屑字典和用于存储整数的基数 62 编码为基础,

存储密钥需要二倍的内存。

数据自定义压缩, 不是对阵列, 而是对一个 loooong int (可以转换 [21, 25-05- 2012, 14-06-2010], 转换为 212505-20121406-2010, 最后两个部分的长度固定, 那么显然如何包装/ 重新包装这种值 )

所以全部的钥匙/价值大小现在比现在少1.75倍

如果你的代码库是以红宝石为基础的,我可以建议我再生宝石,它无缝地执行斯里巴提回答+特定回答的所有想法。