一．当前架构

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

数据库整体架构：目前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度，横向采用了历史库+当前库的分库架构或者单一的当前库架构，其中历史库只作为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)历史数据清理运维工作

在Oracel数库系统中，针对对大流水表每个月的数据进行分区，这样运维人员在清理历史月份的数据时候，只要通过TRUNCATE PARTITION、 DROP PARTITION的Oracle本身的分区维护命令轻松快速清理掉分区的数据（既指定月份的流水数据）

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

同样Oracle也有等同于sybase的统计量更新工作，在Oracle中通过对大流水表的分区工作后，进行统计量的更新工作同样就快捷简易，可以通过ANALYZE PARTITION的统计量分析维护命令可以轻松快速对指定分区的统计量进行更新。

3.运维监控纰漏的改进

主要分两个方面：a)数据库剩余空间方面的监控；b)数据库出错日志的监控。这两个监控虽然通过人为主动性的查看数据库相关信息可以监控到，但是总归还是会有疏忽遗漏的时候，只是出问题几率高低之分。所以这里再加一道监控，就是通过数据库服务器端的监控程序主动发回有问题或者告警的信息给运维人员。这道监控程序可以通过shell程序以及数据库程序，结合数据库日志以及剩余空间信息以短信或者邮件的方式发回给运维人员。在数据库剩余空间方面甚至可以通过数据库本身阀值的设置，做到自动截取日志，自动添加设备。

4.运营统计报表数据模型的改进

由于原先一些报表模型存在着数据统计的重复性，在晚上定时task中既占用了任务列表的总时间，也对其他并行的task运行造成了一定的资源争用，影响了数据库性能。所以在这里提出了一种类似蒲公英性质的模型，数据通过发散模式，即插即用到不同的运营统计报表中，势必需要改进当前接近一事一地的3范式模型，把原先的数据模型拆散，从纵向和横向都接近最小粒度需求的数据模型。使得统计数据可以重复使用，不同的统计报表通过这些原子性的统计数据再组合成报表所需要的数据，当然这里需要一个平衡，并不完全等同蒲公英模型的统计粒度越细越好，因为越细也代表着原始的统计数据量越大，一会影响原始统计的性能，二会影响组合成报表的性能，三会占用更多的存储空间。这个平衡度需要掌控好。

5.利用集群技术

当然通过了前面4点的改进之后，数据库性能会比目前的架构提升一定的性能，至于集群技术就可以作为前面4点改进后的补充和扩展，如果在改进后，依然还存在较大性能瓶颈情况下可以采用Oracle RAC技术。甚至采用基于内存数据库的分布式数据库架构的混合集群技术。比如在Oracle数据库及Web服务之间加一层 Ameoba 分布式数据库代理结合内存数据库的架构，

6.分库架构完善改进

目前的数据库架构采用了分库方式，但是主库（当前库）的读写却是没有分离的，纵观淘宝的数据库架构演进历程，确是在某个历程碑点做到了很好的读写分离，应用到DB的数据写入与查询从双向通行变成了单向通行，通行效率更高，大大避免了相互影响。“借道行驶”的情况不再出现。淘宝那个碑点做到了以下几点：

1)写库为集中式的oracle环境,提供数据安全性保障。

2)读库使用mysql, 采用数据分片，分库分表，每台mysql放少量的数据,单个数据分片内部采用mysql复制机制。

3)读库的超大memory容量，起到了很好的cache作用，在内存中的数据查询性能远远高于在硬盘上的性能

4)oracle到多台mysql按规则复制

结合淘宝架构的思考，校讯通大流水也可以做到垂直分割到不同的服务器，也可以做到水品分割到不同的服务器，通过不同的服务器访问不同的流水表或者是不同范围数据的流水表，那提升性能是肯定的。不过也要平衡考虑到应用程序开发的简便性。

7.内存数据库技术利用

常见的内存数据库产品包括商业版和免费版两类。商业版如：Altibase，Timesten，Berkley DB等。他们在电信，金融，证券等高性能计算应用中运用较为广泛。商业版功能强大，然而，价格比较昂贵，不适合目前“廉价PC+免费软件”的架构搭建思想。

开源领域产品主要有H2，HsqlDB，Derby，BerkeleyDB 等。在混合集群架构中，内存数据库将承担OLTP的职责，因此除了读写性能外，功能的完备，事务等都需要作为优先评估的因素。

盛传H2是一个开源的高性能内存数据库，可以通过整合 Ameoba 与 H2，夹在applications和传统db层之间来达到内存数据库层的架构部署。

Ameoba 是分布式数据库代理，它与 MySQL 整合已经在阿里巴巴核心业务中成功运用。如果仅将数据库节点看作一个存储，MySQL Node 和 H2 Node 并无本质区别。JDBC驱动，DB切分，路由，皆由Ameoba 统一负责。

8.非关系型数据库的使用

外围的非核心数据，但是数据量又是比较大的的业务系统数据库可以采用非关系型数据库，这是由非关系型数据库的一些基本特性决定的。

非关系型数据库有满足如下需求的优点特性：

1)High performance - 对数据库高并发读写的需求

2)Huge Storage - 对海量数据的高效率存储和访问的需求

3)High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

但同时伴随不能满足以下需求的缺点：

1)数据库事务一致性需求

2)数据库的写实时性和读实时性需求

3)对复杂的SQL查询，特别是多表关联查询的需求

正是由于以上的优缺点也决定了，核心的需要保持一致性的数据，需要复杂关联的数据，需要实时访问的数据不要采用关系型数据库，如果通过ETL把关系型数据库的流水数据冗余基本信息，组成可以直接查询的业务信息数据，导入到非关系型数据库后，那对海量流水数据的查询速度提升空间是很大的。其中代表型的非关系型数据有Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai，ThruDB等等非常之多。

四．架构计划

通过以上当前架构劣势以及改进思路的总结，改善的架构计划就比较清晰了，以下还是通过横向的整体数据库架构，纵向的整体数据库架构，以及数据模型的架构改进来做为新的架构计划。

风险最小，改动工作量最小的架构就是改进思路中以第4点和第5点之间为分割线。这条分割线前的数据架构基本不需要变动，主要变动的就是数据模型架构中的流水表对象，以及数据库服务器后台添加监控以及智能处理的运维程序工具。
主要改进的数据模型流水表对象如下图：

同样进行分区的还有其他的一些大流水表，这里不一一详述，这些流水表从sybase进入oracle的分区表，在数据库转型升级过程中完成。

还有一点就是关于数据库监控工具在架构中的部署，如下图所示：

以上架构改进计划可以在一期中先完成。看运行效果状态，第5点之后的改进计划几乎就是架构的重构了，所以涉及的工作量更大，如果在第1，2，3，4点改进后数据库运行稳定，后续的改进，可以通过实验和应用结合逐步实施起来，作为应付更大型的业务应用技术储备。

下面结合5，6，7，8点的改进思路做个架构规划，也就是分布式的内存与传统数据库结合的混合集群架构模式，再加上外围产品的非关系型数据库，如下图所示（服务器和db合为同个节点说明，否则图片篇幅占用过大）：

上面的架构图中，application（应用服务层），data cache层，disk db layer层已经实现，但是disk db Layer层的多数据库集群技术还没不能说正式实现，虽然分库技术有类似集群嫌疑，async write（异步写）听开发人员也已经涉及使用。那么此新架构图针对原架构的改进就是Memory DB Layer层以及类似Ameoba （可以使用其他的代理）分布式数据库代理还没实现。Memory DB Layer集群加上每个逻辑分区有两个内存库是为了其中一个内存数据库一旦崩溃，同一逻辑分区中的替补节点立即顶替工作，做到健壮的容错和Failover机制。这个架构明显比校讯通当前在使用的架构要复杂很多，稳定性以及性能的提升都有待实际验证，虽然单单从架构上来讲融合了目前很多的技术优点（集群，内存数据库等）。