1.数据库存储问题
由于tcp不定时不间断的上报数据,1秒10条左右,这样高频率的操作数据库一定是不合理的,那怎么来解决问题呢。
ps:我用TCP收集上报上来的ip地址(源IP+目的IP),如果已经存储了就更新访问次数,如果源源ip没有存储,就新增,一次会有多条源IP+目的IP;
我的想法是把处理逻辑放到存储过程中实现:
(1)数据进入临时表
(2)存储ip的A表与临时表通过sql比较,相同的插入,不同的更新访问次数。
(3)将A表的源IP过滤重复,生成一个新表,用于业务需要。
现在的效率是调用一次存储过程花费的时间是400ms左右,1秒可以存储2次。而存储过程的接口是可以支持批量插入的。所以需要一个缓存,把收集的记录缓存起来,批量执行效果更好。
但是,需要考虑几个问题:
1.缓存大小,根据存储过程一次执行批量更新的大小
2.执行存储过程的时机,2种情况,
(1)缓存达到限定大小。
(2)一段时间检查缓存是否有数据未提交。
(3)同时操作缓存问题。
批量执行没有实现,可以尝试一下看看,效果。
由于tcp不定时不间断的上报数据,1秒10条左右,这样高频率的操作数据库一定是不合理的,那怎么来解决问题呢。
ps:我用TCP收集上报上来的ip地址(源IP+目的IP),如果已经存储了就更新访问次数,如果源源ip没有存储,就新增,一次会有多条源IP+目的IP;
我的想法是把处理逻辑放到存储过程中实现:
(1)数据进入临时表
(2)存储ip的A表与临时表通过sql比较,相同的插入,不同的更新访问次数。
(3)将A表的源IP过滤重复,生成一个新表,用于业务需要。
现在的效率是调用一次存储过程花费的时间是400ms左右,1秒可以存储2次。而存储过程的接口是可以支持批量插入的。所以需要一个缓存,把收集的记录缓存起来,批量执行效果更好。
但是,需要考虑几个问题:
1.缓存大小,根据存储过程一次执行批量更新的大小
2.执行存储过程的时机,2种情况,
(1)缓存达到限定大小。
(2)一段时间检查缓存是否有数据未提交。
(3)同时操作缓存问题。
批量执行没有实现,可以尝试一下看看,效果。