(完整版)数据架构规划

数据架构规划

一．当前架构

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

数据库整体架构：目前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度，横向采用了历史库+当前库的分库架构或者单一的当前库架构，其中历史库只作为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版本，存在较多BUG,在索引统计量更新过程中可能导致数据库出现病态，进而影响第二天数据库的正常运行。

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

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

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

由于用户需求的渐进性，导致数据库统计报表在数据模型设计时没有站在至高点，随着用户需求的不断积累，数据库统计报表对象也跟着不断积累，发现目

前存在比较大一部分的统计报表数据在不同数据库对象之间重复统计，没有充分发挥统计数据的重用性。

5.没利用集群技术

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

6.分库架构还可完善

当前的分库架构还可以继续完善，引用成熟的数据库主从分离，读写分离技术。

7.内存数据库技术还没充分利用

当前的数据库架构虽然在前端使用了memcache技术，但是还可以继续完善使用内存数据库技术再结合异步写技术，使得架构相得益彰。

8.适合海量数据高并发读写，高效率存储的非关系型数据库没充分利用

当前的数据库架构还没采用正在兴起的NoSql，NewSql技术（目前部分外围系统采用了mongodb来做试验品，而这部分系统的数据量并不大，非关系

型数据库海量数据高并发访问的高效性优势没有体现出来，从而也没掌握真正的使用经验），当然这种数据库也有缺点，就是数据库事务一致性，数据库的写实时性和读实时性，复杂的SQL查询，特别是多表关联查询是无法满足的。

三．改进思路

在第二部分的劣势现象中，总结了当前数据库架构以及数据模型架构的缺陷，缺陷还比较多，从另外一个角度也反映了公司产品数据库架构改进和提升的空间还比较大，将来随着不断的迭代改进，可以承受的业务量提升的空间也相应的比较大。

下面就根据劣势现象进行针对性的阐述改进思路：

1.流水表性能瓶颈改进

Sybase12.5没有很好的解决大数据量表的性能问题，但是通过数据库转到Oracle后，充分利用Oracle分区表，分区索引的特性来提升流水表的访问性能，逻辑上表仍然是一张完整的表，只是将表中的数据在物理上存放到多个表空间(物理文件上，这样查询数据时，不至于每次都扫描整张表。由于逻辑上仍旧一表，使得应用程序不需要修改，也避免了这个劣势点描述的带来额外许多开发工作量的问题，但是效果几乎等同水平分割数据模型。

2.大流水表运维难的改进

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