我已经阅读了有状态流处理概述，如果我理解正确，RocksDB 被用作键值存储的默认实现的主要原因之一是一个事实，即与内存中的集合不同，它可以处理数据大于可用内存，因为它可以刷新到磁盘。这两种类型的存储都可以在应用程序重新启动后继续存在，因为数据是作为 Kafka 主题备份的。
但是还有其他区别吗？例如，我注意到我的持久状态存储为每个主题分区创建了一些 .log 文件，但它们都是空的。
简而言之，我想知道用内存中的存储替换持久存储的性能优势和可能的风险是什么。
问问题
7187 次
2 回答
6
我对 Kafka Streams 的内部结构和状态存储的不同用例的了解非常有限，尤其是。内存中与持久性，但到目前为止我设法了解到的是持久性状态存储是存储在磁盘上（因此名称为持久性）的StreamTask.
这并没有给出太多，因为内存中的名称本身与持久化的名称可能给出了相同的理解，但是当我了解到 Kafka Streams 尝试将分区分配给分配了分区的相同 Kafka Streams 实例时，我发现非常令人耳目一新之前（重新启动或崩溃）。
也就是说，每次重新启动时都会简单地重新创建（重放）内存中的状态存储，这需要一段时间才能启动并运行 Kafka Streams 应用程序，而持久状态存储是已经在磁盘上实现的东西，并且是 Kafka Streams 实例唯一具有的时间重新创建状态存储的方法是从磁盘加载文件（而不是从需要更长时间的变更日志主题）。
我希望这会有所帮助，如果我错了（或部分正确），我会很高兴得到纠正。
于 2019-08-01T09:04:08.293 回答
2
我看不出有任何真正的理由来交换当前的 RocksDB 存储。实际上 RocksDB 是最快的 k,v 存储之一： Percona benchmarks（基于 RocksDB）
with in-memory ones- RocksDB 已经在内存中充当了一些LRU算法：
The three basic constructs of RocksDB are memtable, sstfile and logfile. The memtable is an in-memory data structure - new writes are inserted into the memtable and are optionally written to the logfile.
但是选择这个实现还有一个更明显的原因：
如果您查看源代码比率 - 代码中Java暴露了很多 api C++。Java - based因此，使用公开的 api 将该产品集成到现有的 Kafka 生态系统中并全面控制存储要简单得多。
于 2019-05-31T14:48:32.473 回答