数据架构规划样本.docxVIP

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。

数据架构规划

一．当前架构

??结合研发二部数据量最大的校讯通产品来描述,其它的产品在性能上出现瓶颈,能够向校讯通靠拢。

数据库整体架构:当前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度,横向采用了历史库+当前库的分库架构或者单一的当前库架构,其中历史库只作为web平台读数据库,纵向结合了applications的memcache+SybaseASE12.5传统永久磁盘化数据库架构。

数据模型架构:原则上采用了一事一地的数据模型(3NF范式),为了性能考虑,一些大数据量表适当的引用了数据冗余,根据业务再结合采用了当前表+历史表的数据模型。

以下就用图表来进行当前数据架构的说明:

横向分库数据库架构图:

?

纵向applayer+memcachelayler+diskdblayer图:

其中web层指的是客户端浏览器层,逻辑上:app层指的是应用服务层,mc层指的是memcache的客户端层,ms层指的是memcache的服务层,db层指的是当前永久磁盘化的数据库层,当然在物理机器上可能app层跟mc层,ms层是重叠的部署在相同服务器上。

数据模型架构图:

??其中以上数据模型中除了少数几张表外其它的都有历史表存在,当然有很多表是没在这个模型图中的,这部分是核心数据模型。这部分模型对象中也包括了一些冗余性的设计,比如用户中有真实姓名,特别是不在这个模型内,由模型核心表产生的一些统计报表,为了查询的性能冗余了合理一些学校名称,地区名称等方面的设计。

?

二．劣势现象

1.流水表性能瓶颈

??当前架构的性能瓶颈集中在流水表的访问上,最大流水表的记录量达到了超5亿级别,这是由于当前外网在用的sybase数据库系统版本,没有采取很好的关于分区的技术。曾经有过把流水表进行物理水平分割,把不同月份的数据分割放在不同的物理表上的模型改造设想,碍于产生的应用程序修改工作量大,老旧数据迁移的麻烦,再加上进行了从单库架构改造到分库架构后,数据库性能瓶颈就不是特别突出。因此模型改造这部分工作没展开。

无论是单库或是分库的模式,出现平台访问数据库的性能瓶颈依然集中在大流水表上,在访问高峰高并发量情况下,短信的流水表进程堵塞,数据库服务I/O,CPU的资源耗费达到顶点,在服务器硬件环境不是特别理想情况下,出现了一定概率造成用户访问缓慢甚至觉得页面无法响应现象,造成了用户体念不良影响。

?

2.运营维护难点

??1)历史数据清理运维工作

??为了存储充分利用,为了性能的提升,需要定期进行不再使用的历史数据清理,

由于清理的数据量庞大,传统的数据清理方法根本不可能保证一个晚上有效清理完毕,确保平台第二天正常的运行。虽然当前已经实行了比较高效且可行的数据清理方法,可是每次实行都需要晚上到通宵进行处理,使得数据清理的运维工作特别劳累,影响到运维人员第二天的正常出勤,间接就有可能影响到数据库的正常运维监控,导致数据库问题出现。

??2)防止索引失效而进行的统计量更新运维工作

??由于流水表数据变动量大,容易导致流水表的索引失效,从而需要定期的进行索引甚至整表的统计量更新工作,统计量更新时间跟流水表的数据总量成正比关系,所以导致统计量更新速度比较慢,不能确保在计划时间内,统计量更新的完全成功,而且当前外网安装的sybase12.5版本是最低一个的EBF版本,存在较多BUG,在索引统计量更新过程中可能导致数据库出现病态,进而影响第二天数据库的正常运行。

?

3.运维监控纰漏(此部分非架构原因引起)

??当前的数据库监控以及运维维护还存在一些纰漏,出现了多次数据库设备空间使用完毕,没有及时添加数据库设备空间导致数据库挂起问题,也多次出现了数据库日志空间占满导致数据库挂起问题。此类问题还是比较明显,还有一类问题,不是整库挂起,而是部分业务表访问异常,运维可能监控不到,等用户访问到了这部分业务功能不正常,由用户反馈到运维这边。

?

4.运营统计报表在当前数据模型架构下重用性较低

??由于用户需求的渐进性,导致数据库统计报表在数据模型设计时没有站在至高点,随着用户需求的不断积累,数据库统计报表对象也跟着不断积累,发现当前存在比较大一部分的统计报表数据在不同数据库对象之间重复统计,没有充分发挥统计数据的重用性。

?

5.没利用集群技术

??当前的数据库架构还没采用成熟的集群技术,集群技术并不单单指单一数据库系统的集群,能够混合集群,比如内存数据库跟传统永久磁盘化