我正在研究是否使用Redis缓存大型数据集。
最大的数据集包含大约5百万个对象。虽然每个对象都有唯一的标识符，但客户从不单独使用它们;对整个数据集执行聚合和连接操作。
目标环境是4台服务器，每台服务器具有144 Gb Ram，24核和千兆网卡 - 运行Windows 2008 R2企业。在这种程度上，我在每个盒子上安装了10个来自Microsoft Open Technologies的Redis-64.2.6.12.1实例。我正在使用ServiceStack的Redis客户端。
我已将数据分片为1000个对象的块（这似乎提供了最佳性能）并使用ShardedRedisClientManager来散列每个块ID以在40个缓存中分布数据。持久化对象映射，以便客户端应用程序可以仅使用数据集ID继续检索所有对象。 Redis列表用于对象和对象映射。
交易没有改善性能，但是通过连接对夹头进行分组，并行处理确实如此。但表现仍不尽如人意。设置然后获得5米对象加上对象图的最佳时间是268055毫秒。
那么，有没有更好的方法来使用Redis缓存大型数据集？缓存此类数据集是否合理？我应该如何处理序列化到磁盘并将处理移动到数据ala hadoop？
答案 0 :(得分：1)
问题不在于Redis是否适合大型数据集，而是您的数据集和用例是否适合Redis。
Redis本质上允许您维护分布式计算机科学集合，并允许您以每个数据集合类型允许的最佳Big O表示法性能以Threadsafe原子方式访问和交互它们。
Redis可能很快，但它仍受网络延迟和最佳数据存储和访问模式的限制，例如：您仍然需要关注所需的网络往返次数和带宽，无论您是数据访问是需要全表扫描还是可以通过自定义索引和您正在使用的序列化库的性能开销来减少。
每次想要传输整个DataSet似乎很奇怪，这可能表明您不应该将数据集维护并将其逐项列入Redis服务器集合。如果您只是访问和操作客户端上的数据集，那么将数据存储到Redis集合中并没有什么好处。
如果你是用例是我可以将5M对象水合成内存中的.NET数据结构的最快方法，那就是将整个数据集作为blob存储到单个GET / SET条目中使用像ProtoBuf或MessagePack这样的快速二进制格式。通过这种方式，Redis只是表现得像一个快速的内存blob存储。如果不需要分发（即通过网络访问）对数据存储的访问，则比Level DB这样的快速嵌入式数据存储更加优化。
为了获得最佳性能，您可以更进一步，使用GETRANGE/SETRANGE从多个复制的redis服务器读取块，或者只是将序列化的二进制blob块化为多个分片的redis服务器 - 尽管这意味着如果没有它们，块自身就没用了整个聚合，因此损坏的块会使整个数据集无效。