algorithm - Redis:大型键集的高效键分片

Question

我遇到了超出服务器 RAM 容量的问题。我需要减小数据库大小，以便仍然可以使用 Redis。我的应用程序是一个巨大的键/值存储，其中键是用户给定的文本字符串(目录/文件路径)。这些值是指向我创建的对象的非常简单的指针。所以它是一个对象存储。问题是我有一个 PB 的对象，其中一个对象可能是 100K 字节。我实际上可以将平均对象限制为不小于 1M 字节，因此 10^15/10^6 = 10^9 个对象。因为每个对象都需要一个 key ，即 10^9，或 1G key 。如果每个键/值对为 100 个字节，则 RAM 中有 100GB。这几乎适合具有 128GB RAM 的服务器，但它并不是服务器中唯一发生的事情。如果可以的话，我想减少足迹。

问题是往哪个方向走？我尝试压缩输入键，但在我的测试中它实际上比原来的要大，因为它是一个很短的字符串而不是文档。我考虑过为较小的文件使用不同的数据存储，假设低于 1G。这将减少我需要放入 Redis 的内容。我还考虑过使用一种有意重叠和分箱键的哈希算法，然后将哈希增量作为值放入合并的键中。如果这太令人困惑，这里是一个虚构的例子:

Key    Hash
A       15gh2
B       15gh2
C       4Tgnx

然后我会存储在 Redis 中: V(15gh2) = A, B, A-Value=A-Object, B-Value=B-Object

V(4Tgnx) = C

可能有一种合适的方法来代数表示它，但我不知道该怎么做。 “A-Object”是我指向 A 对象的指针。根据我读到的一些关于 key 比 Redis 哈希值更昂贵的帖子(不要将“Redis 哈希”与“哈希”算法混淆)，我想要做的是最终得到更少的 key 。我可以访问 http://ieeexplore.ieee.org/完整的数据库来搜索关于这个主题的论文。我不太确定应该在查询字段中搜索什么？我尝试过“哈希链”之类的东西，但这似乎比高效的数据库存储更针对加密。任何解决方案想法或更深入研究的途径都将不胜感激。

更新:如评论部分所述，值或我所说的“A-Object”、“B-Object”是经过编码的“指针”，它们是对象的路径。这些是 XFS 文件系统中的实际文件。它们可以简单地编码为“1:6:2”以指向路径“/data/d0001/d0006/d0002”。所以只需要存储一个非常短的值“1:6:2”。

Answer 1

处理这么多数据的标准方法是跨多个服务器对数据进行分区。

参见 http://redis.io/topics/partitioning寻求有关如何做到这一点的建议。