Différence entre KTable et magasin local
Quelle différence entre ces entités?
Comme je pense, KTable - simple kafka sujet avec compaction politique de suppression. De plus, si la journalisation est activée pour KTable, il y a aussi le journal des modifications et ensuite, la politique de suppression est compaction,delete.
Magasin local - Cache de valeur-clé en mémoire basé sur RockDB. Mais le magasin local a également un journal des modifications.
Dans les deux cas, nous obtenons la dernière valeur de clé pour une certaine période de temps (?). Le magasin local est utilisé pour les étapes d'agrégation, les jointures, etc. Mais un nouveau sujet avec une stratégie de compactage est également créé après.
Par exemple:
KStream<K, V> source = builder.stream(topic1);
KTable<K, V> table = builder.table(topic2); // what will happen here if i read data from topic with deletion policy delete and compaction? Will additional topic be created for store data or just a local store (cache) be used for it?
// or
KTable<K, V> table2 = builder.table(..., Materialized.as("key-value-store-name")) // what will happen here? As i think, i just specified a concrete name for local store and now i can query it as a regular key-value store
source.groupByKey().aggregate(initialValue, aggregationLogic, Materialized.as(...)) // Will new aggregation topic be created here with compaction deletion policy? Or only local store will be used?
Je peux également créer un magasin d'état en utilisant le générateur builder.addStateStore(...) où je peux activer/désactiver la journalisation (changelog) et la mise en cache (???).
J'ai lu ceci: https://docs.confluent.io/current/streams/developer-guide/memory-mgmt.html , mais certains détails ne sont toujours pas clairs pour moi. Surtout le cas lorsque nous pouvons désactiver StreamCache (mais pas le cache RockDB) et que nous obtiendrons une copie complète du système CDC pour la base de données relationnelle
Un KTable est une abstraction logique d'une table qui est mise à jour au fil du temps. De plus, vous pouvez le considérer non pas comme une table matérialisée, mais comme un flux de journal des modifications qui comprend tous les enregistrements de mise à jour de la table. Comparez https://docs.confluent.io/current/streams/concepts.html#duality-of-streams-and-tables . Par conséquent, conceptuellement, un KTable est quelque chose d'hybride si vous le souhaitez, cependant, il est plus facile de le considérer comme un tableau mis à jour au fil du temps.
En interne, un KTable est implémenté à l'aide de RocksDB et d'un sujet dans Kafka. RocksDB, stocke les données actuelles de la table (notez que RocksDB n'est pas un magasin en mémoire et peut écrire sur le disque). Dans le même temps, chaque mise à jour de KTable (c'est-à-dire à RocksDB) est écrite dans une rubrique correspondante Kafka. Le Kafka La rubrique est utilisée pour des raisons de tolérance aux pannes (notez que RocksDB lui-même est considéré comme éphémère et l'écriture sur le disque via RocksDB ne fournit pas de tolérance aux pannes, mais la rubrique de journal des modifications utilisée) et est configurée avec le compactage des journaux activé pour vous assurer que la dernière l'état de RocksDB peut être restauré en lisant le sujet.
Si vous avez un KTable créé par une agrégation fenêtrée, la rubrique Kafka est configurée avec compact,delete Pour que les anciennes données expirées (c'est-à-dire les anciennes fenêtres) éviter que la table (c.-à-d. RocksDB) se développe sans limite.
Au lieu de RocksDB, vous pouvez également utiliser un magasin en mémoire pour un KTable qui n'écrit pas sur le disque. Ce magasin aurait également une rubrique de journal des modifications qui suit toutes les mises à jour du magasin pour des raisons de tolérance aux pannes.
Si vous ajoutez un magasin manuellement via builder.addStateStore(), vous pouvez également ajouter RocksDB ou des magasins en mémoire. Dans ce cas, vous pouvez activer le changelogging pour la tolérance aux pannes similaire à un KTable (notez que quand une KTable est créée, en interne, elle utilise exactement la même API - c'est-à-dire un KTable est une abstraction de niveau supérieur cachant certains détails internes).
Pour la mise en cache: ceci est implémenté dans Kafka Streams et au-dessus d'un magasin (soit RocksDB ou en mémoire) et vous pouvez activer/désactiver pour les magasins "simples" que vous ajoutez manuellement, pour pour KTables. Comparez https://docs.confluent.io/current/streams/developer-guide/memory-mgmt.html Ainsi, la mise en cache est indépendante de la mise en cache RocksDB.