给定一组答案的一些补充：
首先，如果您要有效地使用Redis哈希，则必须知道键计数的最大数量和值的最大大小-否则，如果它们超出了哈希的hash-max-ziplist-value或hash-max-ziplist-entries，Redis将在幕后将其转换为实际上是常规键/值对。（见hash-max-ziplist-value，hash-max-ziplist-entries）而从哈希选项下面的故障确实很糟糕，因为Redis中每个常规键/值对使用+90字节。
这意味着，如果您选择选项二并意外突破了max-hash-ziplist-value，那么您将会获得每个用户模型内每个属性+ 70字节！
redis = Redis.include(MeRedis).configure( hash_max_ziplist_value: 64, hash_max_ziplist_entries: 512 ).new
=> #<Redis client v4.0.1 for redis://127.0.0.1:6379/0>
> redis.flushdb
=> "OK"
> ap redis.info(:memory)
{
"used_memory" => "529512",
**"used_memory_human" => "517.10K"**,
....
}
=> nil
> redis.pipelined{ 10000.times{ |i| redis.me_set( "t:#{i}", txt[rand(50000), 63] ) } }; :done
=> :done
> ap redis.info(:memory)
{
"used_memory" => "1251944",
**"used_memory_human" => "1.19M"**,
.....
}
> redis.flushdb
=> "OK"
> redis.pipelined{ 10000.times{ |i| redis.me_set( "t:#{i}", txt[rand(50000), i % 512 == 0 ? 65 : 63] ) } }; :done
> ap redis.info(:memory)
{
"used_memory" => "1876064",
"used_memory_human" => "1.79M",
....
}
redis.pipelined{ 10000.times{ |i| redis.set( "t:#{i}", txt[rand(50000), 65] ) } };
ap redis.info(:memory)
{
"used_memory" => "2262312",
"used_memory_human" => "2.16M",
....
}
对于TheHippo的答案，关于第一个选项的评论是误导性的：
如果需要所有字段或多个get/set操作，则hgetall/hmset/hmget可以解决问题。
对于BMiner的答案。
第三个选项实际上非常有趣，对于max(id) < has-max-ziplist-value的数据集，该解决方案的复杂度为O(N)，因为，惊喜，Reddis将小哈希存储为类似于长度/键/值对象的数组式容器！
但是很多时候哈希只包含几个字段。当哈希很小时，我们可以将它们编码为O(N)数据结构，例如带有长度前缀的键值对线性数组。由于仅在N很小时才这样做，因此HGET和HSET命令的平摊时间仍为O(1)：哈希表将在其包含的元素数量增加得太多时转换为真正的哈希表。
但你不用担心，你会很快打破hash-max-ziplist-entries，然后你现在实际上就是解决方案1了。
第二个选项最有可能在幕后进入第四个解决方案，因为问题陈述如下：
请记住，如果我使用哈希，值的长度是不可预测的。它们并非都像上面的生物示例那样短。
正如你已经说过的：第四个解决方案是最昂贵的，每个属性肯定要增加70个字节。
我的建议如何优化此类数据集：
你有两个选择：
如果您无法保证某些用户属性的最大大小，则可以选择第一种解决方案，如果内存问题非常重要，则在将用户JSON存储在Redis之前进行压缩。
如果您可以强制所有属性的最大大小，则可以设置hash-max-ziplist-entries/value，并使用哈希作为每个用户表示形式的一个哈希或从Redis指南的此主题中使用哈希内存优化：https://redis.io/topics/memory-optimization 并将用户存储为JSON字符串。无论哪种方式，您也可以压缩长用户属性。
