我读过 Redis 和 RocksDB,我没有得到 Redis 相对于 RocksDB 的优势。
我知道 Redis 都是内存中的,而 RocksDB 是内存中的并且使用闪存存储。如果所有数据都适合内存,我应该选择哪一个?他们有同样的表现吗?Redis 与 CPU 的数量成线性关系?我想还有其他我没有得到的差异。
我有一个适合内存的数据集,我打算选择 Redis,但 RocksDB 似乎为我提供了相同的功能,如果有一天数据集增长太多,我不必担心内存。
他们没有任何共同之处。您正在尝试在这里比较苹果和橙子。
Redis 是一个远程内存数据存储(类似于 memcached)。它是一个服务器。单个 Redis 实例非常高效,但完全不可扩展(关于 CPU)。Redis 集群是可扩展的(关于 CPU)。
RocksDB 是一个嵌入式键/值存储(类似于 BerkeleyDB 或更准确地说是 LevelDB)。它是一个库,支持多线程和基于日志结构合并树的持久性。
虽然 Didier Spezia 的回答在他区分这两个项目时是正确的,但它们由一个名为LedisDB的项目链接。LedisDB 是一个用 Go 编写的抽象层,它在 RocksDB 等存储引擎之上实现了大部分 Redis API。在许多情况下,您可以直接将相同的 Redis 客户端库与 LedisDB 一起使用,在某些情况下几乎可以替代 Redis。Redis 显然更快,但正如 OP 在他的问题中提到的那样,使用 RocksDB 的主要好处是您的数据集不受可用内存量的限制。我发现这很有用,不是因为我正在处理超大型数据集,而是因为 RAM 很昂贵,而且您可以从较小的虚拟服务器中获得更多的里程。
许多 memcached 服务器使用 Redis(其中使用的协议是 memcached,但底层服务器是 Redis)。这没有使用 Redis 的大部分功能,但是 Redis 和 RocksDB 的功能相似的一种情况(作为 KVS,尽管仍然处于不同的上下文中,其中基于 Redis 的 memcached 是缓存,但 RocksDB 是数据库,尽管不是企业级)
@Guille 如果您知道热数据的行为(经常获取)是基于时间戳的,那么 Rocksdb 将是一个明智的选择,但请使用bloom-filters对其进行优化以供回退。如果您的热数据是随机的,那么请使用 Redis . 在 Rocksdb 等日志结构数据库中通常不建议在内存中完全使用 RocksDB,它专门针对 SSD 和闪存存储进行了优化。所以我的建议是了解用例并为该特定用例选择数据库。
Redis 是分布式的内存数据存储,而 Rocks DB 是嵌入式键值存储而不是分布式的。