性能讨论
- 时间: 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
- （肖）还得考虑动态表字段拼接等，多表关联时如何拼接
- （邓）调度下单，选择设备时。调度的身份是确定的啊，某条线+某个专业
- （邓）调度会跨专业下单，或跨线路下单？
- （邓）同意还有故障的管理，故障体系的管理等 会跨吗？
- （坤）思路同意分库分表，怎么分，是根据业务特点来的
- （邓）有些业务逻辑性强的，你还得做分布式事务控制
