文档介绍：数据架构计划
一．目前架构
    结合研发二部数据量最大校讯通产品来描述，其它产品在性能上出现瓶颈，能够向校讯通靠拢。
数 据库整体架构：现在校讯通产品依据用户量多少和数据库服务资源繁忙程度，横向采取了历史库+目前库分库架构或单一目前库架构，其中历史库只作 为web平台读数据库，纵向结合了applicationsmemcache+Sybase 。
数据模型架构：标准上采取了一事一地数据模型（3NF范式），为了性能考虑，部分大数据量表合适引用了数据冗余，依据业务再结合采取了目前表+历史表数据模型。
以下就用图表来进行目前数据架构说明：
横向分库数据库架构图：
 
纵向app layer+memcache layler+disk db layer图：
其中web层指是用户端浏览器层，逻辑上：app层指是应用服务层，mc层指是memcache用户端层，ms层指是memcache服务层，db层指是现在永久磁盘化数据库层，当然在物理机器上可能app层跟mc层，ms层是重合布署在相同服务器上。
数据模型架构图：
    其中以上数据模型中除了少数几张表外其它全部有历史表存在，当然有很多表是没在这个模型图中，这部分是关键数据模型。这部分模型对象中也包含了部分冗余 性设计，比如用户中有真实姓名，尤其是不在这个模型内，由模型关键表产生部分统计报表，为了查询性能冗余了合理部分学校名称，地域名称等方面设 计。
 
二．劣势现象
    目前架构性能瓶颈集中在流水表访问上，最大流水表统计量达成了超5亿等级，这是因为现在外网在用sybase数据库系统版本，没有采取很好相关 分区技术。曾经有过把流水表进行物理水平分割，把不一样月份数据分割放在不一样物理表上模型改造设想，碍于产生应用程序修改工作量大，破旧数据迁移 麻烦，再加上进行了从单库架构改造到分库架构后，数据库性能瓶颈就不是尤其突出。所以模型改造这部分工作没展开。
无 论是单库或是分库模式，出现平台访问数据库性能瓶颈仍然集中在大流水表上，在访问高峰高并发量情况下，短信流水表进程堵塞，数据库服务I/O ,CPU资源花费达成顶点，在服务器硬件环境不是尤其理想情况下，出现了一定概率造成用户访问缓慢甚至认为页面无法响应现象，造成了用户体念不良影响。
 
2. 运行维护难点
    1)历史数据清理运维工作
    为了存放充足利用，为了性能提升，需要定时进行不再使用历史数据清理，
由 于清理数据量庞大，传统数据清理方法根本不可能确保一个晚上有效清理完成，确保平台第二天正常运行。即使现在已经实施了比较高效且可行数据清理方 法，不过每次实施全部需要晚上到通宵进行处理，使得数据清理运
维工作尤其劳累，影响到运维人员第二天正常出勤，间接就有可能影响到数据库正常运维监 控，造成数据库问题出现。
    2)预防索引失效而进行统计量更新运维工作
    因为流水表数据变动量大，轻易造成流水表索引失效，从而需要定时进行索引甚至整表统计量更新工作，统计量更新时间跟流水表数据总量成正比关系，所 以造成统计量更新速度比较慢，不能确保在计划时间内，统计量更新完全成功，，存在较 多BUG,在索引统计量更新过程中可能造成数据库出现病态，进而影响第二天数据库正常运行。
 
（此部分非架构原因引发）
    目前数据库监控和运维维护还存在部分纰漏，出现了数次数据库设备空间使用完成，没有立即添加数据库设备空间造成数据库挂起问题，也数次出现了数据库日 志空间占满造成数据库挂起问题。这类问题还是比较显著，还有一类问题，不是整库挂起，而是部分业务表访问异常，运维可能监控不到，等用户访问到了这部分业 务功效不正常，由用户反馈到运维这边。
 
    因为用户需求渐进性，造成数据库统计报表在数据模型设计时没有站在至高点，伴随用户需求不停积累，数据库统计报表对象也跟着不停积累，发觉现在存在比较大一部分统计报表数据在不一样数据库对象之间反复统计，没有充足发挥统计数据重用性。
 
    目前数据库架构还没采取成熟集群技术，集群技术并不单单指单一数据库系统集群，能够混合集群，比如内存数据库跟传统永久磁盘化数据库系统集群。
 
    目前分库架构还能够继续完善，引用成熟数据库主从分离，读写分离技术。
 
    目前数据库架构即使在前端使用了memcache技术，不过还能够继续完善使用内