使用Redis哈希与许多密钥的性能比较 [英] Performance comparison of using Redis hashes vs many keys

问题描述

好的，我目前正计划将Redis用作NoSQL数据库的前端缓存。我将在Redis数据库中存储很多常用的用户数据。我想知道是否为每个用户创建一个键值条目会更好，还是使用 Redis哈希其中的字段更好是用户ID ，值是一个大的 json对象。您认为什么会更好？

Okay, I'm currently planning on using Redis as a front end cache to my NoSQL database. I will be storing a lot of frequently used user data in the Redis database. I was wondering if making a key-value entry for each user would be better or using the Redis hash where the field is the user id and the value is a large json object. What do you think would be better?

我看到了这篇文章可以回答这个问题，但它没有讨论局限性

I saw this article to sort of answer the question, but it doesn't discuss the limitations on value size.

推荐答案

在哈希 > string 有很多优点和缺点，具体取决于用例。如果您要选择哈希，最好将json对象设计为哈希字段&值，例如；

Choosing hash over string has many benefits and some drawbacks depending on the use cases. If you are going to choose hash, it is better to design your json object as hash fields & values such as;

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 优于字符串正确的数据建模。

Here are the benefits of hash over strings when you do a proper data modeling.

• 在性能方面，大多数用于字符串和哈希的命令都具有相同的复杂性。


• 与字符串进行比较时，更容易访问/更新/删除散列上的各个json字段。您无需获取整个字符串，进行解码，进行更改并重新设置。您可以使用 HDEL ， HSET 或 HGET 用于这些操作，而无需获取整个对象


• 如果字符串对象的大小增加，则在传输（获取/设置）整个对象时会遇到网络和带宽的问题。如文档

• On the performance side most of the commands for both strings and hash have same complexity.
• Access/update/delete individual json fields on hashes easier when it is compared to the strings. You don't have to get the whole string, decode, make changes and set it again. You may use HDEL, HSET or HGET for those operations without getting the whole object.
• If the size of your string object increases, you will suffer from network and bandwidth while transferring(get/set) the whole object. As it is stated in the documentation

RAM的速度和内存带宽对于全局性能似乎不太重要，特别是对于小型对象。对于大对象（> 10 KB），它可能会变得很明显。

Speed of RAM and memory bandwidth seem less critical for global performance especially for small objects. For large objects (>10 KB), it may become noticeable though.

• 如果使用散列，则与字符串相比，散列对内存更友好您将成为设计数据大小的良好基准。正如文档中所述，以及 instagram工程，您可能会获得巨大收益


• Hashes are more memory friendly than string if you make good benchmark to design your data size. As it is stated in the documentation and an example use case by instagram engineering you may get a huge benefit with the special encoding.




哈希，列表，仅由整数组成的集合和有序集合（小于a）给定数量的元素以及最大的元素大小，都以一种非常节省内存的方式进行编码，该方式使用的内存减少多达10倍（平均节省的内存减少了5倍）。

Hashes, Lists, Sets composed of just integers, and Sorted Sets, when smaller than a given number of elements, and up to a maximum element size, are encoded in a very memory efficient way that uses up to 10 times less memory (with 5 time less memory used being the average saving).

另一方面，取决于您的用例；

On the other hand, depending on your use case(s);



• ziplist 不是免费提供的，这是内存和cpu之间的折衷。


• 您不能部分使哈希字段过期。如果您将多个字符串划分为多个字符串，则可以 EXPIRE ，但是在散列中，只有顶级键的所有值才能到期。


• ziplist doesn't come for free, it is a tradeoff between memory and cpu.
• You can't partially expire hash fields. If you divide into the multiple strings then you may EXPIRE them but in hashes only the top level key can be expired with all the values.

这篇关于使用Redis哈希与许多密钥的性能比较的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！