最近在用python/java 对sr进行操作。
对于更新数据的场景，因为python或者java的框架或者这种方式，导致数据在更新的时候经常出现：because of too many versions, current/limit: 1001/1000 的问题。该问题很清楚是频率太高，tablet来不及合并version导致。
对于这种业务逻辑里，需要大量更新数据的场景，比如：update ods_cs_image_info set ai_model_handle_status=%s where id=%s 这种语句，这里id不一样。如何进行处理和操作能不出现too many versions的问题，谢谢
对于这种用代码操作表的情况， 有什么做法吗？谢谢
看官网配置参数：
update_compaction_per_tablet_min_interval_seconds
- 默认值：120
- 类型：Int
- 单位：Seconds
- 是否动态：是
- 描述：主键表每个 Tablet 做 Compaction 的最小时间间隔。
- 引入版本：-
这个意思是每隔120做一次Compaction ，所有如过120秒以内如果更新量达到1000，就会出现 too mang versions？
看样子，你是利用JDBC的方式进行每一条数据的更新，是否可以将update操作变更为streamLoad方式，指定部分更新列，然后进行攒批的方式去达到更新的效果呢。这样应该可以解决because of too many versions的问题，当然这只是我的一个想法，也不知道是否合理
明白你说的，现在是用在一个业务系统的增删改查功能上，所有不太好用其他方式
另外一个问题是：如果更新语句，比如1000条数据，如果更新的where 条件只有一个值，那是可以直接更新。如果更新的where条件值不一样，那会出现这个问题。这个是什么原因呢