Hi, yangxueyong, If the ratio will not be modified frequently, we could set a long TTL for the cache in the lookup table to reduce the frequency of reading, or put a cache in the UDF. If you need the exact ratio when the data arrives, we have to read it from the remote storage each time we get new data.
Best, Hang yangxueyong <yangxuey...@nantian.com.cn> 于2023年5月6日周六 18:08写道： > Thank you very much for your reply. We have also thought about this > solution, but our transaction volume is very large, and the TPS reaches > thousands. We are worried that reading the database will become a > performance bottleneck. I think we can also read redis, but you still have > Any other options? > > 在 2023年5月6日 17:54，Hang Ruan<ruanhang1...@gmail.com> 写道： > > Hi, yxy, > > I think this scenario could be resolved by a lookup join or a UDF. We can > store the ratio in the mysql table. Then we could read it by a lookup join > or implement a UDF to read the ratio. > > Best, > Hang > > yxy <yangxuey...@nantian.com.cn> 于2023年5月6日周六 15:14写道： > >> Hello, we have a business scenario. We have a real-time process to >> calculate how much red envelopes should be given to them for each >> transaction. For example, if a customer pays $100, we will give him a >> rebate of one thousandth. We currently use flinksql to Realize this >> function, but we found that flinksql cannot dynamically adjust this ratio. >> We want to know can flinksql implement broadcast tables like this? >> Broadcast the ratio? > >
