Kstream相对于状态存储的成本与KTable的成本
我试图更好地理解如何设置我的集群来运行我的Kafka-Stream应用程序。我正试图更好地了解将涉及的数据量。
在这方面，虽然我可以很快地看到一个KTable需要一个状态存储，但我想知道从一个主题创建一个Kstream是否意味着立即将该主题的所有日志以一种仅追加的方式复制到状态存储中。也就是说，特别是如果我们要公开流以供查询？
当源主题是Kstream时，当它们在源主题中移动时，Kafka是否自动复制状态存储中的数据？正如上面所说的，这对于Ktable来说听起来很明显，因为更新了，但是对于Kstream来说，我只想确认发生了什么。
共有1个答案
每当调用任何有状态操作或在窗口化流时，都会创建状态存储。
KTable需要一个状态存储，这是对的。KTable是changelog流的抽象，其中每个记录都表示一个更新。在内部，它是使用RocksDB实现的，其中所有更新的值都存储在状态存储区和一个changelog主题中。在任何时候，都可以从changelog主题重新构建状态存储。
虽然KStream有一个不同的概念，但它表示对记录流的抽象，并使用仅追加格式的无界数据集。它在读取源主题时不创建任何状态存储。
-
我们有以下高级DSL处理拓扑： 简而言之，我们在上面做的是： null 其思想是创建窗口化事件计数，并将这些窗口化键用于联接和聚合操作（在KTable的情况下，这类操作没有窗口） 问题是：join和aggregate操作的状态存储没有保留机制，并导致磁盘（RocksDB）中的空间爆炸。 更具体地说：（跳跃）窗口会在键上产生笛卡尔积，并且没有删除旧窗口的机制。 请注意，支持table1和table2
-
我正在使KStream-KStream连接，其中创建2个内部主题。而KStream-KTable join将创建1个内部主题+1个表。 就性能和其他因素而言，哪个更好？
-
当您知道中对象/项的确切数量时，我很想知道内存分配的首选方法是什么对性能（例如，运行时间）有好处Linux。少量对象（少量内存）和大量对象（大量内存）的成本。 例如，类型A【N】vs 请让我知道。非常感谢。 注意：我们可以对此进行基准测试，并可能知道答案。但我想知道解释这两种分配方法之间性能差异的概念。
-
我正在尝试以下列方式使用kafka流实现事件源模式。 我在一家安全服务公司工作，处理两个用例: 注册用户，处理 应生成 。 更改用户名，处理 应生成 。 我有两个主题： 命令主题，每个命令都是键控的，密钥是用户的电子邮件。例如： 实现思想可以用以下拓扑表示： 对于这个拓扑，我使用的是。 此拓扑的更显式版本： 我遇到的问题： 在具有现有记录的命令主题上启动流应用程序： 在构建这样的拓扑时，我缺少什么
-
我是React的新手，你能告诉我这是什么意思吗？
-
全局状态存储与普通状态存储有何不同？ 全局状态存储是否在不同机器上运行的所有实例中都有数据副本？由于全局状态存储不使用任何更改日志主题进行恢复，因此在重新启动时它的行为在我的场景中全局存储的源主题没有键。