性能讨论

• 时间: 2017年7月16日晚上~17日早上
• 发起人: 张总、肖总
• 参与人: 管理软件事业部全体成员
• 议题:
  • 各项目现状与背景
  • 各项目组对大数据量性能优化方案讨论

问题发表

• （肖）问：南宁项目每天统计问题数不合理，12号60，14号0，16号50

• （坤）答：问题不累计，发现就改

• （腾）答：测试员人建议配置，重庆项目压力测试没人做（注：没有额外人员配置专门做，现在由肖总兼做）

• （张）问：导入200万数据后，my sql性能如何，卡死现象是数据库还是设计的问题

• （肖）答：上周针对设备表已经完成优化，190万的数据，按专业分表

• （肖）答：加索引后基本满足要求，但还要进一步优化

• （肖）答：性能是多方面

重庆项目的优化方案讨论

• （肖）基础表按专业分表，如设备。业务表按年归档，单表保持的数据在200万左右，上两周解决的难点
• （肖）分表加索引，结合业务查询条件控制
• （腾）模糊查找用不了索引，编程的时候要注意
• （肖）分表，一般不建议按两个维度分了，要不然，引入的编程就会复杂
• （肖）如按线路+专业分表，表的结构可能会是这样的：m_asset_line1_tri
• （肖）还得考虑动态表字段拼接等，多表关联时如何拼接
• （肖）重庆项目两年的数据已经到千万级了，我南宁只有一条线估计没这么快的增长量。按朱总的想法，重庆很有可能会有两条新线的其他专业纳入系统，数据量增长会更快。所以我还是按专业的模式设计分表，按公司模式分库，工单业务表按月度或年度归档。以适应专业的扩展，分公司模式，和多年运行性能的保证。

优化方案讨论

张总声音

• 是否有优化方案
• 我们现在的设计要考虑到南宁线网形成，运营有几千人使用的情况。不这样考虑，以后系统会重写，得不偿失
• 要考虑眼前问题，但也要考虑到以后几年的问题。在设计思路上要清楚，落实可以分步走

肖总声音

• 看了昨晚讨论了半天，没实质的思路和解决方案，重庆项目两年的数据已经到千万级了，我南宁只有一条线估计没这么快的增长量。按朱总的想法，重庆很有可能会有两条新线的其他专业纳入系统，数据量增长会更快。所以我还是按专业的模式设计分表，按公司模式分库，工单业务表按月度或年度归档。以适应专业的扩展，分公司模式，和多年运行性能的保证。
• 很多场景都要关联设备表，但设备表还是比较大的，设备表是如何考虑的
• 缓存不了吧，数据有200万，需要多少内存才能缓存呵
• 200万很少，不是缓存所有字段，只缓存，查询需要的。例如：id、wbs、name就差不多了
• 分线路+分专业分库或分表后，设备单表的数据还会去到多少？
• 分表，一般不建议按两个维度分了，要不然，引入的编程就会复杂
• 这些理论都明白，现在要是找到编程和数据量的一个平衡点
• 分表后，要根据分表的条件，路由到对应的分表进行查询
• 如按线路+专业分表，表的结构可能会是这样的：m_asset_line1_tri
• 还得考虑动态表字段拼接等，多表关联时如何拼接

邓总声音：

• 优先解决重要紧急问题
• 看公司管理模式，按线路管则按线路分库，如果按专业管就按专业分库
• 我们思路就是分库分表，优化查询
• 重庆的管理模式是按线路管理的，我建议先按线路，再按专业分库。原因是线路之间交叉管理的较少，专业交叉的更少
• 绩效考核及报表都是以月度为单位，可以考虑按月度分
• 对于基础数据，几乎不会有太多变化，可以考虑直接全部缓存到内存中
• 重庆的管理模式是按线路管理的，我建议先按线路，再按专业分库。原因是线路之间交叉管理的较少，专业交叉的更少
• 报表的统计数据按月度结余的方式全部用中间表存放
• 在前期如果数据量还可以控制时，可以先用视图。量大后采取定时任务在闲时进行结余计算统计
• 所以，对于购买的框架，你这把要向厂商了解，他们的缓存、分库、分表是如何实现的。
• 在硬件方面也要提前考虑，逻辑服务器的数量及部署方案，每台服务器的最大并发极限是多少。这个也可以让厂商提供
• mysql表的数据量达到百万级时，普通SQL查询效率呈直线下降，而且如果where中的查询条件较多时，其查询速度简直无法容忍。所有查询条件其实应该尽量减少
• 所有在业务上可以考虑wbs的利用，减少查询条件。南宁这把这个是没有做好的
• 设备表，按线路、按专业分库或分表，然后再缓存，设备表数据做好后，几乎不会变化
• 同意还有故障的管理，故障体系的管理等 会跨吗？

乾坤声音：

• 没有好的服务器，只有pc机，再怎么优化，也就那样，数据再多点还是顶部住，买了好服务器，上固态，快的狠
• 分表，分库，读写分离，预先计算，集群，都可以用啊
• 现在200完支持，多一百万，有可能就不是一个数量级的增加时间啊
• 数量是可以估算，要做性能测试，要在正式服务器同样的配置环境下测试
• 这个还是要综合考虑，在必要合理的设计下，如果服务器完全没问题，就没必要浪费几个月的时间去优化，而且讲究性能的同时，要考虑开发的复杂度和可靠性啊，这些都会增加成本啊
• 要是还顶部住叫客户加服务器，加固态硬盘，用集群
• 其实最好的的方案就是上mongodb+hadoop,分裤分表只是止痒，机器摆在那，而且这些那出去吹那是刚刚的，嘿嘿
• 思路同意分库分表，怎么分，是根据业务特点来的

讨论过程摘录：

• （坤）有好的服务器，只有pc机，再怎么优化，也就那样，数据再多点还是顶部住，买了好服务器，上固态，快的狠
• （张）是否有优化方案
• （坤）分表，分库，读写分离，预先计算，集群，都可以用啊
• （张）我们现在的设计要考虑到南宁线网形成，运营有几千人使用的情况。不这样考虑，以后系统会重写，得不偿失。
• （坤）现在200完支持，多一百万，有可能就不是一个数量级的增加时间啊
• （邓）优先解决重要紧急问题
• （坤）数量是可以估算，要做性能测试，要在正式服务器同样的配置环境下测试
• （张）要考虑眼前问题，但也要考虑到以后几年的问题。在设计思路上要清楚，落实可以分步走。
• （邓）有考虑
• （坤）这个还是要综合考虑，在必要合理的设计下，如果服务器完全没问题，就没必要浪费几个月的时间去优化，而且讲究性能的同时，要考虑开发的复杂度和可靠性啊，这些都会增加成本啊
• （邓）看公司管理模式，按线路管则按线路分库，如果按专业管就按专业分库
• （邓）我们思路就是分库分表，优化查询
• （坤）要是还顶部住叫客户加服务器，加固态硬盘，用集群
• （邓）月度结余统计也是为分表作的准备
• （腾）12360招标的时候，大铁说谁能解决就谁来做，钱不是问题，全国没人投标。不是硬件堆起来就可以解决的
• （肖）看了昨晚讨论了半天，没实质的思路和解决方案，重庆项目两年的数据已经到千万级了，我南宁只有一条线估计没这么快的增长量。按朱总的想法，重庆很有可能会有两条新线的其他专业纳入系统，数据量增长会更快。所以我还是按专业的模式设计分表，按公司模式分库，工单业务表按月度或年度归档。以适应专业的扩展，分公司模式，和多年运行性能的保证。
• （邓）重庆的管理模式是按线路管理的，我建议先按线路，再按专业分库。原因是线路之间交叉管理的较少，专业交叉的更少
• （邓）绩效考核及报表都是以月度为单位，可以考虑按月度分
• （邓）对于基础数据，几乎不会有太多变化，可以考虑直接全部缓存到内存中
• （邓）重庆的管理模式是按线路管理的，我建议先按线路，再按专业分库。原因是线路之间交叉管理的较少，专业交叉的更少
• （邓）报表的统计数据按月度结余的方式全部用中间表存放
• （邓）在前期如果数据量还可以控制时，可以先用视图。量大后采取定时任务在闲时进行结余计算统计
• （邓）所以，对于购买的框架，你这把要向厂商了解，他们的缓存、分库、分表是如何实现的。
• （邓）在硬件方面也要提前考虑，逻辑服务器的数量及部署方案，每台服务器的最大并发极限是多少。这个也可以让厂商提供
• （邓）mysql表的数据量达到百万级时，普通SQL查询效率呈直线下降，而且如果where中的查询条件较多时，其查询速度简直无法容忍。所有查询条件其实应该尽量减少
• （肖）很多场景都要关联设备表，但设备表还是比较大的，设备表是如何考虑的
• （邓）所有在业务上可以考虑wbs的利用，减少查询条件。南宁这把这个是没有做好的
• （邓）设备表，按线路、按专业分库或分表，然后再缓存，设备表数据做好后，几乎不会变化
• （肖）缓存不了吧，数据有200万，需要多少内存才能缓存呵
• （肖）200万很少，不是缓存所有字段，只缓存，查询需要的。例如：id、wbs、name就差不多了
• （坤）其实最好的的方案就是上mongodb+hadoop,分裤分表只是止痒，机器摆在那，而且这些那出去吹那是刚刚的，嘿嘿
• （肖）分线路+分专业分库或分表后，设备单表的数据还会去到多少？
• （肖）分表，一般不建议按两个维度分了，要不然，引入的编程就会复杂
• （肖）这些理论都明白，现在要是找到编程和数据量的一个平衡点
• （肖）分表后，要根据分表的条件，路由到对应的分表进行查询
• （肖）如按线路+专业分表，表的结构可能会是这样的：m_asset_line1_tri
• （肖）还得考虑动态表字段拼接等，多表关联时如何拼接
• （邓）调度下单，选择设备时。调度的身份是确定的啊，某条线+某个专业
• （邓）调度会跨专业下单，或跨线路下单？
• （邓）同意还有故障的管理，故障体系的管理等 会跨吗？
• （坤）思路同意分库分表，怎么分，是根据业务特点来的
• （邓）有些业务逻辑性强的，你还得做分布式事务控制