【问题标题】:Redis : Pros and Cons for following two approachesRedis:以下两种方法的优缺点
【发布时间】:2016-03-14 16:23:55
【问题描述】:

我有很多 javascript 对象,例如:

var obj1 = {"key1" : value1, "key2" : value2, ...}
var obj2 = {"key3" : value3, "key4" : value4, ...}

等等……

以下是两种方法:

  1. 将每个对象存储为 Redis 哈希,即一对一映射。
  2. 拥有一个 Redis 哈希(可以进行存储以获得更好的性能),将每个对象作为字符串化对象存储在哈希的每个键中,即对于在 Redis 哈希中具有键值对的每个对象。当我们需要使用对象时解析对象。

1) -> 比 2) 占用更多空间,但比 2) 具有更好的性能

2) -> 占用的空间比 1) 少,但性能比 1) 差

有没有办法确定从长远来看哪种方法更好?

更新:此数据用于客户端(AngularJS),因此所有字符串化 JSON 的解析都在前端完成。

【问题讨论】:

  • 您需要搜索单个字段,还是只是在寻找 id->document 映射?
  • 是的,我也需要搜索各个字段。

标签: data-structures redis hashmap


【解决方案1】:

这可能会通过确定哪种方法最小化从 redis 提取所需数据所需的步骤数来解决。

案例 1: 大量嵌套对象
如果你的对象有很多嵌套,即对象中的对象,像这样,
obj = {key1:{key2:value1, key:3{key4:value2}}}

您可能应该对它们进行字符串化并存储。
因为 Redis 不允许数据结构的嵌套。您不能将哈希存储在另一个哈希中。 并且将 hash2 的名称作为 key 存储在 hash1 中,并在获取 hash1 后查询 hash2 等等都是不必要的复杂并且有很多查询。在这种情况下,您所要做的就是从 Redis 和 JSON.parse 获取整个字符串。你可以从对象中得到你想要的任何数据。

案例 2: 没有嵌套对象。
但另一方面,如果没有嵌套对象,并且将其存储为字符串,则每次从 Redis 获取数据时都必须JSON.parse()。并且解析 JSON 是阻塞的并且是 CPU 密集型的。 Node.js: does JSON.parse block the event loop?

Redis 文档还说,哈希是在一个非常小的空间中编码的,因此您应该尽可能尝试使用哈希来表示您的数据。 http://redis.io/topics/memory-optimization

因此,在这种情况下,您可能会继续将它们全部存储为单独的哈希值,因为查询特定值会容易得多。

---------更新---------
即使在客户端完成 JSON 解析,也尽量不要进行不必要的额外计算 :)
但是嵌套对象更容易作为字符串存储和查询。否则,您将不得不查询多个哈希表。在这种情况下,存储为字符串化对象可能会更好地提高性能。

Redis 非常有效地存储小散列。以至于存储多个小哈希图比一个大哈希图更节省内存。
决定使用编码的键的数量可以在 redis.conf 中找到
hash-max-zipmap-entries 512
每个键的值也应该是hash-max-zipmap-value 64
因此,您现在可以根据对象的嵌套、Redis 内存效率更高的 Hash Key 的数量以及分配给您的键的值来决定。

一定要通过http://redis.io/topics/memory-optimization

【讨论】:

  • 这些数据将在前端使用(我想我应该提到过),我使用 Angular 来解析字符串化的 JSON,因此服务器没有解析任何对象的负载。
  • @AmanGupta 即使这样,嵌套对象也最好存储为字符串。否则,您将不得不查询多个哈希图以获取您想要的数据。如果没有嵌套对象,请继续并将它们存储为单独的哈希值。如果对象的数量大于 zipmap 条目的值,您可能还希望将它们存储为单独的哈希值。
  • 我没有嵌套对象,所以我们可以解决这个问题。 Instagram 也使用了第二种方法,所以我很好奇他们为什么要这样做,而且他们这样做有非常充分的理由。
  • 嗯。如果没有嵌套,我实际上没有看到为什么应该使用第二种方法(如您的问题中所述)的原因。 Redis 文档显然更喜欢第一种方法来存储与内存消耗相关的哈希值。虽然在性能方面稍微慢了一点。
猜你喜欢
  • 2011-11-01
  • 2011-02-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-10-13
  • 2010-10-29
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多