小编Kar*_*all的帖子

在Redis中,keys user*将打印所有键user.例如:

keys user*
1) "user2"
2) "user1"

现在,我希望user打印所有不能启动的键.我怎么能这样做？

我一直致力于流数据的聚合,我找到了两个实现相同的工具.他们是德鲁伊和管道.我已经理解了两者的实现和架构.但无法想出一种方法来对这两者进行基准测试.是否已经完成了现有的基准测试？或者,除了速度和可扩展性之外,如果我想对自己进行基准测试,那么我需要考虑的因素是什么.任何想法,链接和帮助都会非常明显.同时与pipelinedb和druid分享您自己的经验

谢谢

从文档中我们知道 redis 对某个范围内的数据进行压缩（默认为 512）。如果哈希范围超过 512，则内存差异将是 10 倍。

我对从 1 到 512 的哈希值做了一个小实验，发现了一些有趣的模式。

此图表示 1000 个哈希所占用的内存（以 KB 为单位），每个哈希包含 1 到 512 的条目。

正如您在此图中所见。在某些时间间隔内存在陡峭。我了解 redis 中的哈希实现也遵循一些逻辑，用于在达到某个范围时扩展大小，而不是为每个新条目增加它。从数字来看，它并没有始终遵循加倍模式，但从 215 到 216，它确实加倍了，4 MB 到 8 MB。从 420 到 421，它几乎增加了 8 MB 到 12 MB 的一半。在 215 度以内的陡坡中，我看不到它在 1/4、1/5 和 1/6 之间变化的任何模式。

根据我的观察，以下是我的问题：

1. 有人可以解释一下 hashmap 在内存和调整大小方面的内部情况吗？调整大小时遵循的逻辑是什么？
2. 如果我不得不为了再存储一个 215 到 216 的条目而释放双倍内存，为什么我不能限制我的应用程序的哈希值始终小于 215，除非并且直到系统最多需要它。
3. 假设我想存储 100 万个散列，每个散列由 250 个值组成，我需要 800MB。如果我将它们分成 2 个 125 个值的散列，即 125 个值的 200 万个散列，我需要 500MB。通过这种方式，我节省了 300 MB，这是巨大的！！。这个计算对吗？在这种情况下我错过了什么吗？

提前致谢