好的,我正在计划使用redis作为nosql数据库的前端缓存。我将在redis数据库中存储大量常用的用户数据。我在想,如果 key-value 为每个用户输入或使用 Redis hash 场地在哪里 user id 价值很大 json object . 你觉得什么更好?我看到这篇文章是为了回答这个问题,但它没有讨论价值大小的限制。
key-value
Redis hash
user id
json object
vohkndzv1#
选择 hash 结束 string 根据用例的不同,它有许多优点和缺点。如果要选择hash,最好将json对象设计为hash字段&值,例如;
hash
string
127.0.0.1:6379> hset user:1 ssn 10101010101 name john surname wick date 2020-02-02 location continental (integer) 5 127.0.0.1:6379> hgetall user:1 1) "ssn" 2) "10101010101" 3) "name" 4) "john" 5) "surname" 6) "wick" 7) "date" 8) "2020-02-02" 9) "location" 10) "continental"
以下是 hash 当你做一个正确的数据建模时。在性能方面,用于字符串和哈希的大多数命令都具有相同的复杂性。与字符串相比,访问/更新/删除散列上的单个json字段更容易。你不必得到整个字符串,解码,修改,然后重新设置。您可以使用hdel、hset或hget进行这些操作,而不必获取整个对象。如果字符串对象的大小增加,则在传输(get/set)整个对象时,会受到网络和带宽的影响。如文件所述ram的速度和内存带宽对于全局性能似乎不那么重要,特别是对于小型对象。对于大型对象(>10 kb),它可能会变得很明显。如果在设计数据大小时做了很好的基准测试,哈希比字符串对内存更友好。正如文档和instagram engineering的一个示例用例中所述,使用这种特殊编码,您可能会获得巨大的好处。哈希、列表、仅由整数组成的集和排序集,当小于给定的元素数且达到最大元素大小时,以非常节省内存的方式进行编码,使用的内存最多可减少10倍(平均节省内存5倍)。另一方面,取决于您的用例; ziplist 不是免费的,它是内存和cpu之间的一种折衷。哈希字段不能部分过期。如果你分成多个字符串,那么你可以 EXPIRE 但在散列中,只有顶级键可以与所有值一起过期。
ziplist
EXPIRE
1条答案
按热度按时间vohkndzv1#
选择
hash
结束string
根据用例的不同,它有许多优点和缺点。如果要选择hash,最好将json对象设计为hash字段&值,例如;以下是
hash
当你做一个正确的数据建模时。在性能方面,用于字符串和哈希的大多数命令都具有相同的复杂性。
与字符串相比,访问/更新/删除散列上的单个json字段更容易。你不必得到整个字符串,解码,修改,然后重新设置。您可以使用hdel、hset或hget进行这些操作,而不必获取整个对象。
如果字符串对象的大小增加,则在传输(get/set)整个对象时,会受到网络和带宽的影响。如文件所述
ram的速度和内存带宽对于全局性能似乎不那么重要,特别是对于小型对象。对于大型对象(>10 kb),它可能会变得很明显。
如果在设计数据大小时做了很好的基准测试,哈希比字符串对内存更友好。正如文档和instagram engineering的一个示例用例中所述,使用这种特殊编码,您可能会获得巨大的好处。
哈希、列表、仅由整数组成的集和排序集,当小于给定的元素数且达到最大元素大小时,以非常节省内存的方式进行编码,使用的内存最多可减少10倍(平均节省内存5倍)。
另一方面,取决于您的用例;
ziplist
不是免费的,它是内存和cpu之间的一种折衷。哈希字段不能部分过期。如果你分成多个字符串,那么你可以
EXPIRE
但在散列中,只有顶级键可以与所有值一起过期。