内存与持久性Kafka Streams状态存储

Question

我已经阅读了有状态流处理overview，如果我理解正确，将RocksDB用作键值存储的默认实现的一个主要原因是事实，这与内存集合，它可以处理大于可用内存的数据，因为它可以刷新到磁盘。两种类型的存储都可以在应用程序重新启动后继续存在，因为数据将作为Kafka主题备份。

但还有其他差异吗？例如，我注意到我的持久状态存储为每个主题分区创建了一些.log文件，但它们都是空的。

简而言之，我想知道用内存中替换持久存储的性能优势和可能存在的风险是什么。

Answer 1

我对Kafka Streams的内部结构以及状态存储（尤其是状态存储库）的不同用例的了解非常有限。内存还是持久存储，但是到目前为止，我设法学到的是，持久存储是一种存储在磁盘上（因此名称为 persistent ）的StreamTask。 / p>

这与内存中的 与持久的本身并没有多大区别，但我发现它们令人耳目一新 em>是当我得知Kafka Streams尝试将分区分配给之前分配了分区的同一Kafka Streams实例（重新启动或崩溃）时。

也就是说，每次重新启动时都会简单地重新创建（重放）内存状态存储，这需要一段时间才能启动和运行Kafka Streams应用程序，而持久性状态存储已经是在磁盘上实现，并且Kafka Streams实例唯一需要重新创建状态存储的操作是从磁盘（而不是从需要更长时间的changelog主题）加载文件。

我希望能有所帮助，如果我错了（或部分正确），我将很高兴得到纠正。

Answer 2

我看不出交换当前RocksDB存储的任何真正原因。实际上，RocksDB是最快的k，v存储之一： Percona benchmarks (based on RocksDB)

with in-memory ones-RocksDB已经充当内存，其中涉及一些LRU算法：

RocksDB architecture

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.

但是选择此实现还有一个明显的原因：

RocksDB source code

如果您要查看源代码比率-Java代码中公开了许多C++ API。因此，使用公开的api将产品集成到现有Java - based Kafka生态系统中，对商店进行全面控制要简单得多。