Jedis存储混乱，这个问题是Redis还是Jedis的问题？答案

【问题标题】：Jedis Storage Confusion, Is this issue from Redis or Jedis?Jedis存储混乱，这个问题是Redis还是Jedis的问题？
【发布时间】：2011-12-02 01:11:53
【问题描述】：

以下 java 代码将一百万个整数对插入到 redis 中。

 public class JedisInsertion { 
        public static byte[] fromInt(int v) { 
                return ByteBuffer.allocate(4).putInt(v).array(); 
        } 
        public static void main(String args[]) { 
                Jedis j = new Jedis("localhost"); 
                for (int i = 0;i<1000*1000;i++){ 
                   j.set(fromInt(i),fromInt(i)); 
                } 
        } 
}

这里是redis信息输出

... 
used_memory:89319664 
arch_bits:64 
...

89319664 意味着每个键值对大约 89 个字节。

我原本期望大约 8 MB 的大小（4 字节的键 + 4 字节的值）。

我还在 32 位模式下编译了 redis（仍在 64 位模式下运行测试）位机）。

32位版本redis的结果：

used_memory: 68831664 => 每个键值对 68 个字节。

这两个结果都比我预期的要高几倍。

当我使用 CLI 查看 redis 时，我看到一个典型的键如下所示："\x00\x00\xc2\xff"

感谢您的反馈

PS - 我在 64 位机器上使用 Redis 2.2.14 和 Jedis 2.0

PSS - 我还尝试按照其中一个 cmets 的建议将所有值存储在一个哈希中，代码如下：

for (int i = 0;i<1000*1000;i++){
    j.hset("my-hash".getBytes(),fromInt(i),fromInt(i));
}

结果如下：

used_memory_rss:84676608 (for 32bit build)
used_memory:105319712 (for 64bit build)

当我使用单个哈希时，结果会更糟。

【问题讨论】：

标签： redis jedis

【解决方案1】：

每个键/值类型 68 个字节是正确的。 Redis 不会在内部将内容存储为纯文本文件，否则它将无法快速查找它，无法拥有不同类型的对象等等。有一个相关的开销。 Redis.io 的文档中有更多相关信息。

【讨论】：

【解决方案2】：

您的密钥是不可读的二进制值这一事实是 Jedis 做出的决定，因为 Redis 几乎可以使用任何东西作为密钥。

Redis 键具有过期和其他占用额外空间的元数据。如果您担心空间问题，请考虑将所有值存储在单个 Redis 哈希中。与标准键/值对相比，散列中的键/值对的开销要少得多。

http://redis.io/topics/memory-optimization

【讨论】：