数据库使用情况分析

数据库使用情况分析
一、警报日志：
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支枪，所有枪在一个小时内取或还一次的情况；
以上均没有计算网络传输时间；以及多表联合查询情况；。