redis - 在redis中存储1300万个 float 和整数

Question

我有一个包含 1300 万个 float 的文件，每个 float 都有一个关联的整数索引。文件的原始大小为 80MB。

我们想通过多个索引来获取浮点型数据。唯一的原因是，我需要 hashmap 字段和值，因为 List 不支持传递多个索引来获取。

将它们存储为redis中的hashmap，index为field，float为value。在检查内存使用情况时，它约为 970MB。

存储 1300 万作为列表使用 280MB。

有没有我可以使用的优化。

提前致谢

运行在弹性缓存上

Answer 1

您可以通过创建索引桶与浮点值桶来进行真正好的优化。哈希在内部是非常内存优化的。因此，假设原始文件中的数据如下所示:

index, float_value

2,3.44
5,6.55
6,7.33
8,34.55

并且您当前已将它们存储在散列或列表中的一个浮点值的索引中。您可以对值进行分桶优化:

Hash key为index%1000，sub-key为index，value为float value。

更多详情 here还有:

At first, we decided to use Redis in the simplest way possible: for each ID, the key would be the media ID, and the value would be the user ID:

SET media:1155315 939 GET media:1155315

939 While prototyping this solution, however, we found that Redis needed about 70 MB to store 1,000,000 keys this way. Extrapolating to the 300,000,000 we would eventually need, it was looking to be around 21GB worth of data — already bigger than the 17GB instance type on Amazon EC2.

我们询问了总是乐于助人的 Pieter Noordhuis，Redis 的核心之一 开发人员，用于输入，他建议我们使用 Redis 哈希。散列在 Redis 是可以在内存中编码的字典 有效率的; Redis 设置“hash-zipmap-max-entries”配置 一个散列在仍然存在时可以拥有的最大条目数 高效编码。我们发现此设置最好在 1000 左右；任何 更高，HSET 命令会导致明显的 CPU 事件。为了 更多详细信息，您可以查看 zipmap 源文件。

为了利用哈希类型，我们将所有媒体 ID 存储到 1000 个桶(我们只取 ID，除以 1000 并丢弃 余)。这决定了我们落入哪个键；接下来，在 存在于该键的散列，媒体 ID 是查找键 within 哈希值，用户 ID 是值。一个例子，给定一个媒体 ID 的 1155315，这意味着它落入桶 1155 (1155315/1000 = 1155):

HSET "mediabucket:1155""1155315""939"HGET "mediabucket:1155" “1155315”

"939" The size difference was pretty striking; with our 1,000,000 key prototype (encoded into 1,000 hashes of 1,000 sub-keys each), Redis only needs 16MB to store the information. Expanding to 300 million keys, the total is just under 5GB — which in fact, even fits in the much cheaper m1.large instance type on Amazon, about 1/3 of the cost of the larger instance we would have needed otherwise. Best of all, lookups in hashes are still O(1), making them very quick.

如果您有兴趣尝试这些组合，我们的脚本 用于运行这些测试的 Gist 在 GitHub 上可用(我们也 在脚本中包含了Memcached，作为对比 —— 大约需要52MB 对于百万键)