数据架构规划.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 层是重叠的部署在相同服务器上。 数据模型架构图： 其中以上数据模型中除了少数几张表外其他的都有历史表存在，当然有很多表是没在这个模型图中的，这部分是核心数据模型。这部分模型对象中也包括了一些冗余 性的设计，比如用户中有真实姓名，特别是不在这个模型内，由模型核心表产生的一些统计报表，为了查询的性能冗余了合理一些学校名称，地区名称等方面的设 计。 二．劣势现象 流水表性能瓶颈 当前架构的性能瓶颈集中在流水表的访问上，最大流水表的记录量达到了超5 亿级别，这是由于目前外网在用的 sybase 数据库系统版本，没有采取很好的关于 分区的技术。曾经有过把流水表进行物理水平分割，把不同月份的数据分割放在不同的物理表上的模型改造设想，碍于产生的应用程序修改工作量大，老旧数据迁移 的麻烦，再加上进行了从单库架构改造到分库架构后，数据库性能瓶颈就不是特别突出。所以模型改造这部分工作没展开。 无 论是单库或是分库的模式，出现平台访问数据库的性能瓶颈依然集中在大流水表上，在访问高峰高并发量情况下，短信的流水表进程堵塞，数据库服务 I/O ,CPU 的资源耗费达到顶点，在服务器硬件环境不是特别理想情况下，出现了一定概率造成用户访问缓慢甚至觉得页面无法响应现象，造成了用户体念不良影响。 运营维护难点 历史数据清理运维工作 为了存储充分利用，为了性能的提升，需要定期进行不再使用的历史数据清理， 由 于清理的数据量庞大，传统的数据清理方法根本不可能保证一个晚上有效清理完毕，确保平台第二天正常的运行。虽然目前已经实行了比较高效且可行的数据清理方 法，但是每次实行都需要晚上到通宵进行处理，使得数据清理的运维 工作特别劳累，影响到运维人员第二天的正常出勤，间接就有可能影响到数据库的正常运维监 控，导致数据库问题出现。 防止索引失效而进行的统计量更新运维工作 由于流水表数据变动量大，容易导致流水表的索引失效，从而需要定期的进行索引甚至整表的统计量更新工作，统计量更新时间跟流水表的数据总量成正比关系，所 以导致统计量更新速度比较慢，不能确保在计划时间内，统计量更新的完全成功，而且目前外网安装的 sybase12.5 版本是最低一个的 EBF 版本，存在较 多 BUG,在索引统计量更新过程中可能导致数据库出现病态，进而影响第二天数据库的正常运行。 运维监控纰漏（此部分非架构原因引起） 当前的数据库监控以及运维维护还存在一些纰漏，出现了多次数据库设备空间使用完毕，没有及时添加数据库设备空间导致数据库挂起问题，也多次出现了数据库日 志空间占满导致数据库挂起问题。此类问题还是比较明显，还有一类问题，不是整库挂起，而是部分业务表访问异常，运维可能监控不到，等用户访问到了这部分业 务功能不正常，由用户反馈到运维这边。 运营统计报表在当前数据模型架构下重用性较低 由于用户需求的渐进性，导致数据库统计报表在数据模型设计时没有站在至高点，随着用户需求的不断积累，数据库统计报表对象也跟着不断积累，发现目 前存在比较大一部分的统计报表数据在不同数据库对象之间重复统计，没有充分发挥统计数据的重用性。 没利用集群技术 当前的数据库架构还没采用成熟的集群技术，集群技术并不单单指单一数据库系统的集群，可以混合集群，比如内存数据库跟传统永久磁盘化数据库系统集群。 分库架构还可完善 当前的分库架构还可以继续完善，引用成熟的数据库主从分离，读写分离技术。 内存数据库技术还没充分利用 当前的数据库架构虽然在前端使用了memcache 技术，但是还可以继续完善使用内存数据库技术再结合异步写技术，使得架构相得益彰。 适合海量数据高并发读写，高