joeyutong commented on PR #628: URL: https://github.com/apache/flink-agents/pull/628#issuecomment-4248521750
Thanks for working on this. I’m also looking into Fluss as an ActionStateStore backend, so I’ve been comparing different designs here. One question on the PK table approach: with synchronous upsert in put() and no-op rebuildState(), it seems backend upsert/lookup may sit on the hot path. For new seqNums, get() will usually need to hit Fluss, while the Kafka-style design keeps get() local by rebuilding post-checkpoint state into an in-memory cache. Did you consider using a Log Table instead, plus local cache + recovery marker + changelog rebuild? My main concern is the latency tradeoff of putting PK-table lookup/upsert directly on the action execution path. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
