数据架构规划.pdfVIP

数据架构规划 一．当前架构 结合研发二部数据量最大的校讯通产品来描述，其他的产品在性能上出现瓶 颈，可以向校讯通靠拢。 数 据库整体架构：目前校讯通产品根据用户量的多少以及数据库服务资源的繁 忙程度，横向采用了历史库 + 当前库的分库架构或者单一的当前库架构，其中历 史库只作 为 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) 防止索引失效而进行的统计量更新运维工作 由于流水表数据变动量大，容易导致流水表的索引失效，从而需要定期的进 行索引甚至整表的统计量更新工作， 统计量更新时间跟流水表的数据总量成正比 关系，所 以导致统计量更新速度比较慢，不能确保在计划时