数据库使用情况分析

数据库使用情况分析

一、警报日志：

1）计算一个月插入数据

目前操作为15S会执行一次数据库操作；假设有2000台；那么；一个月的数据为：

单枪柜：

4*60*24*30＝240 0000

如果为2000台：

240*2000＝40000W

这是极限值；

2）计算数据库插入频率

按时间权限处理算下数据库插入操作频率：

15S/2000 =7ms执行一次插入操作

3）数据查询

数据库的数据要与其他的表用ID做关联，那么这个操作会更糟糕；因为警报日志表中在7ms就会执行一个插入动作，所以关联的查询如果在7ms中检索不出来，检索的数据就会有脏数据；（检索和插入动作产生冲突，数据库在处理检索和插入的同时还会处理他们的冲突事情）

由上可以看出数据库的性能要远远高于7ms才可以

以上为单张表警报日志处理极限值分析；

以上解决方法：

1）插入执行时间加长到1个小时，相当于执行极限频率提高到7ms*60*4=5s

2）分库，把此单张表移到一个单独数据库中；

3）换中型数据库MSSQL 或大型数据库ORACLE；

二、取枪还枪日志极限值分析

1）枪弹柜取枪与还枪动插入操作

枪弹柜取枪与还枪动作限定每天执行一支枪一个动作；每个枪弹柜只有十支枪，子弹不用取还计算；

一个枪弹柜一天执行的动作数：

1*10＝10次；

按2000枪弹柜计算：

一个月执行的次数为：

10*2000*30＝30 0000数据；

取还枪表一个月的数据要有30W数据存在；一年大约为400W数据分为两张表，单张表一年数据也近200W；

2）取还枪执行频率

最坏计算：

所有取枪人员在上班同一时间（一小时）取枪计算执行频率为

1*60*60/20000＝0.06S

按上述频率计算，数据库的性能至少是执行每个动作不超过0.06s 就不会产生冲突；（数据不会丢或不会出错），但一般数据库中表关联查询（多表查询）都差不止要这个时间；所以产生冲突的可能必会很大；数据库一定要可以处理这种冲突；

三、整个数据库计算

如果计算最坏情况下数据库的使用频率

应该是：

一个60ms执行一次一个7ms执行一次；最坏计算是420ms产生一次冲突（取还枪与警报日志）；也就是一秒内会有至少产生两次冲突的可能；

而单独警报日志自身不同动作（插入、删除）是0.007S产生一次冲突，数据库会可能会产生一次冲突；

四、解决方案

1）优化数据库和程序代码；

缺点：对程序员和数据库优化人员的技术要求高；

优点：数据库可以继续使用目前数据库

2）数据分库、数据库读写分离；

缺点：程序需要修改

优点：动作很容易实现

3）换大型数据库（MSSQL 或ORACLE）；

缺点：可能需要收费（如果我们项目可以使用破解版本，就可以不用担心），

优点：直接把结构COPY即可；对程序员和数据库优化人员要求低；

4）如果换库建议使用破解版本ORACLE或MSSQL；

五、目前解决方案：

1）警报日志执行单柜频率修改为1小时，即插入动作最坏频率为5S；

2）取枪还枪日志最坏频率为0.06S；

以上看出，后续产生冲突多的是取还枪日志；最坏为0.06秒产生一次冲突；

由警报日志执行频率的0.7ms提升到60ms，应该是基本问题还没有解决；

也就是说明，如果出现最坏情况，取枪还枪日志同样会出现目前这种情况

以上是最坏的计算方式，是极限值仅做参考；是理论存在值，现实出现的可能性不大

以上最坏情况是指2000台柜中的每个柜有10支枪，所有枪在一个小时内取或还一次的情况；

以上均没有计算网络传输时间；以及多表联合查询情况；