数据架构规划.docx

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。数据架构规划一当前架构结合研发二部数据量最大的校讯通产品来描述,其它的产品在性能上出现瓶颈 ,能够向校讯通靠拢。数 据库整体架构 :当前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度 , 横向采用了历史库 +当前库的分库架构或者单一的当前库架构 , 其中历史库只作 为 web平台读数据库 , 纵向结合了 applications 的 memcache+Sybase ASE12.5传统永久磁盘化数据库架构。数据模型架构 : 原则上采用了一事一地的数据模型 ( 3NF 范式 ) , 为了性能考虑 , 一些大数据量表适当的引用了数据冗余 , 根据业务再结合采用了当前表 +历史表的数据模型。以下就用图表来进行当前数据架构的说明:横向分库数据库架构图 :资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。纵向 app layer+memcache layler+disk db layer图:资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。其中 web 层指的是客户端浏览器层 , 逻辑上 : app 层指的是应用服务层 , mc层指的是 memcache的客户端层 , ms 层指的是 memcache的服务层 , db 层指的是当前永久磁盘化的数据库层 , 当然在物理机器上可能 app 层跟 mc层, ms层是重叠的部署在相同服务器上。数据模型架构图 :资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。其中以上数据模型中除了少数几张表外其它的都有历史表存在 , 当然有很多表是没在这个模型图中的 , 这部分是核心数据模型。 这部分模型对象中也包括了一些冗余 性的设计 , 比如用户中有真实姓名 , 特别是不在这个模型内 , 由模型核心表产生的一些统计报表 , 为了查询的性能冗余了合理一些学校名称 , 地区名称等方面的设 计。二劣势现象1. 流水表性能瓶颈当前架构的性能瓶颈集中在流水表的访问上 , 最大流水表的记录量达到了超 5 亿级别 , 这是由于当前外网在用的 sybase 数据库系统版本 , 没有采取很资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。好的关于 分区的技术。曾经有过把流水表进行物理水平分割 , 把不同月份的数据分割放在不同的物理表上的模型改造设想 , 碍于产生的应用程序修改工作量大 , 老旧数据迁移 的麻烦 , 再加上进行了从单库架构改造到分库架构后 , 数据库性能瓶颈就不是特别突出。因此模型改造这部分工作没展开。无 论是单库或是分库的模式 , 出现平台访问数据库的性能瓶颈依然集中在大流水表上 , 在访问高峰高并发量情况下 , 短信的流水表进程堵塞 , 数据库服务 I/O ,CPU 的资源耗费达到顶点 , 在服务器硬件环境不是特别理想情况下 , 出现了一定概率造成用户访问缓慢甚至觉得页面无法响应现象 , 造成了用户体念不良影响。2. 运营维护难点1) 历史数据清理运维工作为了存储充分利用 ,为了性能的提升 ,需要定期进行不再使用的历史数据清理 ,由 于清理的数据量庞大 , 传统的数据清理方法根本不可能保证一个晚上有效清理完毕 , 确保平台第二天正常的运行。 虽然当前已经实行了比较高效且可行的数据清理方 法 , 可是每次实行都需要晚上到通宵进行处理 , 使得数据清理的运维工作特别劳累 , 影响到运维人员第二天的正常出勤 , 间接就有可能影响到数据库的正常运维监 控, 导致数据库问题出现。2) 防止索引失效而进行的统计量更新运维工作由于流水表数据变动量大,容易导致流水表的索引失效,从而需要定期的进行索引甚至整表的统计量更新工作,统计量更新时间跟流水表的数据总量成正比关系 ,所 以导致统计量更新速度比较慢,不能确保在计划时间内 ,统计量更新的完全成功 ,而且当前外网安装的sybase12.5 版本是最低一个的EBF版