解决服务器性能瓶颈

背景
    公司项目组当初对项目开发性能评估不足，统计分析系统服务端与数据库同处一台服务器设备上，数据库中的很多关键数据表数据都由外界多台应用服务器长时间不间断地实时入库产生，平均每分钟有几万笔数据入库，这些数据表企业要求必须最少保存90天数据，日积月累，数据表数据数以千万计，同时入库的这些数据表还是后台定时统计小时及天数据的作业的源表和用户查询实时数据的目标表，极大影响入库、后台统计和查询分析的执行效率，并且很容易产生资源的竞争。运行一年后统计分析系统性能瓶颈日益显现出来，客户十分不满意。

解决方案
    由于数据库与统计分析系统同处一台服务器设备上，数据库负担之重直接影响统计分析系统程序处理性能。在无法扩容硬件资源的情况下尽最大努力优化服务器架构，减少系统资源消耗，提高统计分析系统程序处理性能。
    最大限度地使入库和统计查询分析的数据表不是同一个，并减少单个数据表的容量，采取自动分流存储，优化数据库定时作业：
    1，实时入库的数据以天为单位存储，数据表命名为“原表名+日期”，实时数据入库时自动选择当天数据表，我们就统称源表；
    2，小时数据以月为单位存储，数据表命名为“原小时表名+月份”，后台定时统计作业自动选择当月数据表；
    3，数据库备份和历史数据清理作业计划每周六执行一次；
    4，后台定时统计作业计划每天凌晨1点执行一次；
    5，要求用户使用统计分析系统选择时间范围时不对分钟数据进行跨天查询，不对小时数据进行跨月查询（系统界面有精确到分钟、小时和天数据的查询条件）；
    6，要求报表系统只产生昨天或过去数据，不对今天的数据做报表分析；
 

评论

16 楼 Gorden_Lam 2009-01-21  

应对数据庞大的处理，我们公司是利用offline script去把它们转移，想法挺好的，可以试试。

15 楼 风雪涟漪 2009-01-15  

升级到Mysql5.1 按时间表分区。。性能会显著提升。

14 楼 qilunzhang 2009-01-13  

购买了设备也要加上索引日期

13 楼 eyeieye 2009-01-07  

楼主落伍了，不知道现在红火的是hadoop 这样的dfs了么？是时候抛弃数据库了

12 楼 raymond2006k 2009-01-01  

楼主的方案不错。至少在大家都认为要先添加一个硬件时，楼主在不增加硬件投资的情况下，实现了优化。分表，分区，库表读写分开，这些思路都是必然的思路。

不过，优点是有。缺点也是挺明显的。增加了员工工作上的消耗，程序要做修改，处理难度稍微增加了。

同意很多楼友，你们公司也忒抠门了，做电信项目还没钱！

11 楼 younggun 2008-11-24  

jacklondon 写道

如果性能能够从硬件上解决当然最好。硬件价格年年降，人员工资年年涨，只要稍微想想都知道，能在硬件上解决，往往成本更低，周期更短。
数据库方面的性能优化，insert/delete/update 基本上靠硬件。所以软件技术员能够做的只有 select 了。所以我说的方法安全够用：
其实没有这么复杂：
1. 所有数据放在一个表中
2. 时间字段加索引
3. 查询、报表时，要求用户录入数据开始时间、结束时间，并且，结束时间 - 开始时间 < x 天。
这样就行了。
只是“时间字段”做索引，不同的数据库效率不同。据我的体会，Oracle 时间字段索引要比 SQL server 的快。
当然了，解决数据库性能问题，有必要进行数据库选型测试：同样的数据量，同样的表结构、索引，测试性能，对比。

看来你还的确没有什么在oracle上大数据量的的经验，按照你的方法的话，上亿条数据堆在一个表空间上，表空间很容易形成热区，就算加了索引速度也是无法忍受的，就算不分表，表上分区也是必要的。

10 楼 rogerj 2008-11-19  

谢谢兄弟们的捧场哦！
我这次优化性能明显得到提高！电信用户非常满意！原查询统计要2到3分钟，现在只要10几秒。
其实性能瓶颈就在于入库、查询和统计分析都在同一表上进行，而此表的数据量却非常的大，很容易产生资源的竞争。极大影响入库、统计和查询的执行效率了。只要解决了入库、查询和统计分析的表分开，另外将海量数据分流存储，缩小了查询范围。现在分流存储也大大方便了历史数据的清理，这样的优化非常值得！

9 楼 hocus 2008-11-17  

m8x6bmxb 写道

jacklondon 写道

其实没有这么复杂：
1. 所有数据放在一个表中
2. 时间字段加索引
3. 查询、报表时，要求用户录入开始时间、结束时间，并且，结束时间 - 开始时间 < x 天。
这样就行了。

明显没做过电信应用，你以为就几万条数据啊，你那样做一个表里数据肯定上亿，对这些数据做复杂的查询，如连接、分组、排序及其它计算，估计一个查询一年都出不来！

楼主做的没错，电信报表就是一级一级的生成报表，有时一个表要倒好几次数据，将数据过滤到最少，来提高查询速度！

楼主的系统只是在数据库端做了过滤统计的优化，我们的系统在程序处理的过程中在内存中就先做了一层过滤（目前以小时为单位，为防止系统崩溃丢失内存数据，采用了嵌入式数据库做缓存），数据库再做天及其以上的统计！

lz的数据业务上不要求做处理的，直接入库最好
更像个数据仓库

lz也很明显的知道现在瓶颈是硬件IO了，系统部分再榨取也是有限的
而且你们的系统压力大，硬件似乎也没有可靠性的考虑，双机热备，磁阵，RAID估计都没得，也就只能天天半夜备份了。
数据库横纵分表做了，索引做了，还能在查询上动动脑筋
比如使用存储过程来优化sql
使用缓存来减轻重复读取
用友好的用户界面减缓客户等待的烦躁
唉，苦命的娃

8 楼 hocus 2008-11-17  

魔力猫咪 写道

就看你们进行的这所谓的优化吧。有这些工夫，买台什么服务器买不来。人工不是钱呀。表能改动到这个份上，程序结构的改动也轻不了多少。而且查询代价特别大，这个不成，那个也不许。那还查询分析什么。综合考虑下来，结论是得不偿失。
应该作为反面教材为后人鉴。

数据应用优化有几个方面的
硬件只是一个方面
先不说 硬件的提升也是有极限的，机器持续增加不见得性能就能对应增长
这在多击并行热备时候显现尤为突出

7 楼 Frankie199 2008-11-13  

兄弟，这种情况了都还不加硬件，我真的不知道说什么了。呵呵，估计这个项目没什么钱赚吧。祝你好运

6 楼 wmuu 2008-10-30  

什么单位这么穷，又平均每分钟有几万笔数据入库？

5 楼 m8x6bmxb 2008-10-29  

jacklondon 写道

其实没有这么复杂：
1. 所有数据放在一个表中
2. 时间字段加索引
3. 查询、报表时，要求用户录入开始时间、结束时间，并且，结束时间 - 开始时间 < x 天。
这样就行了。

明显没做过电信应用，你以为就几万条数据啊，你那样做一个表里数据肯定上亿，对这些数据做复杂的查询，如连接、分组、排序及其它计算，估计一个查询一年都出不来！

楼主做的没错，电信报表就是一级一级的生成报表，有时一个表要倒好几次数据，将数据过滤到最少，来提高查询速度！

楼主的系统只是在数据库端做了过滤统计的优化，我们的系统在程序处理的过程中在内存中就先做了一层过滤（目前以小时为单位，为防止系统崩溃丢失内存数据，采用了嵌入式数据库做缓存），数据库再做天及其以上的统计！

4 楼 LucasLee 2008-10-21  

明显的应该使用分区表，按时间分区。

3 楼 nihongye 2008-10-20  

买台机器就完事了。

2 楼 魔力猫咪 2008-10-20  

就看你们进行的这所谓的优化吧。有这些工夫，买台什么服务器买不来。人工不是钱呀。表能改动到这个份上，程序结构的改动也轻不了多少。而且查询代价特别大，这个不成，那个也不许。那还查询分析什么。综合考虑下来，结论是得不偿失。
应该作为反面教材为后人鉴。

1 楼 魔力猫咪 2008-10-20  

好穷。连一台机器都买不起吗？