guzz顺利完成千万级社区网站线上运行

系统介绍:

某大型互动类系统,日均PV2000万左右,总数据量约400G,关系数据库大小30G(不含内容正文)。大约有100多张表。主要是文字业务。

主业务表数据为百万级(100万->800万),归档内容和日志表为千万级。

系统基于Mysql数据库,主从分离部署(1主多从),以前采用hibernate做持久层。

调整后架构:

调整后数据层分为2组数据库,一组为主业务库,一组为归档数据库和日志库。归档和日志库仅仅存放归档表,删除内容表以及日志表,持久层用guzz改写;以前的业务逻辑依然基于hibernate,代码不做任何调整。

调整后数据库模型:
主业务库:1主多从,数据库大小减少至11G。
归档日志库:1主2从。

调整后结果:

1. 目前已经在线上运行超过1个月,系统没有出现任何故障,速度也快了不少。原因可能是由于我们数据库机器只有16G内存,数据量减少后,主业务库的缓存系统更加有效吧。

2. 数据库备份由80分钟降低到30分钟左右。主业务库每天自动dump出来一份做备份,现在快了很多。这样灾难恢复也能快很多(由3小时降低至1小时?)。

3. 主数据库负载大幅度下降。以前我们也做了主从分离,配置hibernate两个sessionFactory,可能是不够彻底,主库负载最高。调整后,主库linux负载降到了0.2以下,mysql连接数也大幅降低了,看起来安全了很多。在Mysql典型结构中,一般主库是瓶颈和单点,降低负载意味着更加稳定和具有扩充性。

4. 主业务数据库的从库负载上升。这是系统负载分布判断错误引起。调整后归档日志库基本上零负载,这些机器本来也是分担一些主业务查询压力的,现在全都转给了主业务库剩下的从数据库了……。机器分配上可能还需要进一步优化,或者将更多辅助业务剥离到归档日志库。

你可能感兴趣的:(数据结构,Hibernate,linux,.net,mysql)