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